What font is used for the UI on linux?

It is a built-in bitmap font, which is essentially just GNU Unifont compiled into a different format.

Also can it be changed?

No.

I believe the reason people are asking this and related questions repeatedly is that the font size is way too small to be a non-configurable UI component. It's a usability and accessibility issue, considering the percentage of the population that have various vision issues with small fonts. Because it's impractical to use reading glasses with a computer display (the distance from screen to eyes is larger than the maximum focal distance for reading glasses), anyone who can't see this super-small font is being put into a situation where they need to strain their neck, back, eyes, etc. to use the UI. This is less-than-ideal UX and it's really annoying for those of us who don't have perfect vision. I've been using CAD software for decades and this is a much harder to use UI than it has to or should be, simply for this reason (otherwise, it's actually a pretty good UI, though it'd be nice to have slightly larger icons).

@supertaz I agree. Unfortunately the amount of engineering work required to use a more reasonable font is massive, even if it might not look so, so it is not an easy fix, or it would have already been done.

That said, the master branch supports HiDPI displays, which is another way to say it supports any integral scale factors. Is it an option for you to run SolveSpace at a 2× or 3× factor?

@whitequark The threads I've seen wrt scaling mentioned issues with definition (blurring), mouse offsets, and latency. While I've got a very high end video card and a huge amount of processing power (very high end workstation used for data science and data engineering in addition to CAD), I'm concerned about the offset and blurring actually making the overall UX worse. At least for me, it's primarily the property browser that's an issue, and 2x is too much magnification for everything but UI icons (even the render time notifications (that I don't generally pay attention to) are more legible, due to being white on black, which is higher contrast than medium/dark blue on black, and the plane hints highlight to bright yellow on black, which is actually the highest possible contrast). I haven't used scaling under Ubuntu (I've never needed it for anything else, as everything else I use obeys WM accessibility cues or has configurable fonts), so I'm reluctant to mess with it. I'm not sure if there's a way to scale a UI to 1.5x in Ubuntu 18.04, but that'd probably be about the right balance between overscaling the workspace and appropriately scaling the property browser.

Honestly, the ability to style the colors used in the property browser might make the too-small font a little easier to read, since higher contrast color choices make it easier to differentiate small text. Is the property browser entirely drawn directly on a canvas, instead of using a portable UI library that can abstract text rendering, toolbars, radio buttons, checkboxes, and color pickers (virtually every UI library covers these)? It seems to me that it'd be simpler to drop the fixed width font in favor of a scalable font and appropriate choices of window size, since it doesn't really seem that there is anything in the UI outside of the drawing window that requires any special handling. Those of us who need more configurability than is currently available usually have large monitors and already have their accessibility options set to make their UI usable everywhere else, so requiring more property browser real estate isn't really an issue when you've probably got an ultrawide display, but blurriness due to scaling can pose a larger or secondary accessibility/usability issue, and it negatively affects the workspace.

I haven't used scaling under Ubuntu (I've never needed it for anything else, as everything else I use obeys WM accessibility cues or has configurable fonts), so I'm reluctant to mess with it. I'm not sure if there's a way to scale a UI to 1.5x in Ubuntu 18.04, but that'd probably be about the right balance between overscaling the workspace and appropriately scaling the property browser.

The scale factor for vector and raster graphics is different. The raster scale factor is controlled by an integer environment variable GDK_SCALE. The vector scale factor (this includes GTK menus and so on, but also 3d graphics in general) is controlled by a floating point environment variable GDK_DPI_SCALE.

Is the property browser entirely drawn directly on a canvas

Correct.

instead of using a portable UI library that can abstract text rendering, toolbars, radio buttons, checkboxes, and color pickers (virtually every UI library covers these)?

There are good historical reasons for not using a portable UI library. It is also not obvious that many UI libraries would be suitable for the task; rendering text in the property browser in the fashion of a markup language allows to implement #319 in the future.

It seems to me that it'd be simpler to drop the fixed width font in favor of a scalable font and appropriate choices of window size

Yes, but this would require a complete rewrite of the property browser code, which is unfortunately very much not easy. That will be done at some point though as it's clearly necessary.

The scale factor for vector and raster graphics is different. The raster scale factor is controlled by an integer environment variable GDK_SCALE. The vector scale factor (this includes GTK menus and so on, but also 3d graphics in general) is controlled by a floating point environment variable GDK_DPI_SCALE.

Raster scaling still leads to pixelization, which makes fonts harder to read, but it's good to know they're separate. That said, this would mean having to launch by commandline every time, as Ubuntu's default launcher doesn't let you set environment variables (at least via UI, which is all many people would want/be able to use) and I definitely don't want the setting to affect anything else.

I still say make that blue text yellow, cyan, pink, or white, and it'll be much easier to read. Rich blues on black are not a great choice for anyone with any kind of eyesight issue. Yellow or white are the best options there, as they are least likely to impact the colorblind.

as Ubuntu's default launcher doesn't let you set environment variables

I'm not sure how the default launcher works these days, but if it lets you edit the command, you can use env GDK_SCALE=2 /usr/bin/solvespace %s or something similar.

I still say make that blue text yellow, cyan, pink, or white, and it'll be much easier to read. Rich blues on black are not a great choice for anyone with any kind of eyesight issue. Yellow or white are the best options there, as they are least likely to impact the colorblind.

OK, I'll keep it in mind.

@supertaz How do you feel about a "high contrast mode" setting that would change all of the colors to white on black except links and group state marker? Or is that going too far?

@supertaz How do you feel about a "high contrast mode" setting that would change all of the colors to white on black except links and group state marker? Or is that going too far?

Sorry for the delay in replying, but I've been out of town. A high contrast mode setting would definitely be helpful, though I don't know if it needs to be effectively monochromatic. That's actually a pretty common approach to high contrast, but meaningful colors can be useful, too, as long as they are high-contrast. For instance, a convention where bright green indicates things that are okay and bright magenta or yellow indicates things that need attention may allow someone who can barely read the text to glean more information than if both were white. Boldface for things that need attention can also help (it also can make it slightly easier to read), but I get that the underlying font difficulties may preclude that approach.

Overall, if the blue were replaced with cyan (for instance), I think it would help a lot, and then a separate high contrast option that was white or yellow on black could definitely be useful as an accessibility option.

As a thought in a similar vein, it also wouldn't hurt to increase the contrast of links when you hover over them; instead of just underlining them in the same color, a higher contrast choice might be helpful (assuming the underline is drawn directly and isn't simply a font component). An alternative would be to change the text color, while still underlining it, again giving more visual reinforcement.

We're currently using both blue and cyan (cyan is used for coordinates in entity properties), so assuming you don't want blue anywhere, that'd need to change color as well.

We're currently using both blue and cyan (cyan is used for coordinates in entity properties), so assuming you don't want blue anywhere, that'd need to change color as well.

Yeah, I wasn't thinking about the contrast with coordinates. The cyan there is fine, but the blue is what needs to be changed. Perhaps a bright and hideous orange for the coordinates, and cyan for the blue? Seriously, though, something that is presented less could be hazard orange, or something equally bright, and still cover both red/green colorblindness (about 8% of males) and blue/yellow colorblindness (very rare, but affects both genders). You could make the colors configurable (back to your high contrast checkbox idea or color themes), as long as that's something you save in a configuration file for the user (if they struggle with getting to the setting every time, it won't be as useful).

Below is an excerpt from https://nei.nih.gov/health/color_blindness/facts_about to help guide you on color choices for the colorblind and color impaired. A good guess is that at least 5% of the people who have tried SolveSpace have had at least a little trouble with parts of the UI due to color, and probably a larger percentage have silently struggled to some extent with the font sizes. I happen to wind up in physical pain when I struggle to read a UI, so I'm proactive about this stuff where others may be silent or just walk away. I think SolveSpace is increasingly advancing to fill a niche that's been desperately lacking for a long time, and don't want to see readability be a stumbling block to the potential to gain a sponsor in the future, which I don't think is unrealistic with a few features like fillets and chamfers in place down the road (see Kicad in the EE schematic space and the amount of money and manpower put in by CERN and the more recent corporate sponsorship of the project lead, who is now able to work on it full time, both of which happened once it got to a place where it could be seriously used every day with the addition of a few critical features, which drove the investment). I suspect those additions would allow you to attract sponsorship for some complex things like arbitrary path extrusion, skinning, patching, and lofting, which in turn would make SolveSpace usable as a cross platform "daily driver" CAD package for a lot of people. If I had the resources to sponsor you right now, I would. Anyway, I digress; on to the excerpt:

Red-Green Color Blindness
The most common types of hereditary color blindness are due to the loss or limited function of red cone (known as protan) or green cone (deutran) photopigments. This kind of color blindness is commonly referred to as red-green color blindness.

Protanomaly: In males with protanomaly, the red cone photopigment is abnormal. Red, orange, and yellow appear greener and colors are not as bright. This condition is mild and doesn’t usually interfere with daily living. Protanomaly is an X-linked disorder estimated to affect 1 percent of males.
Protanopia: In males with protanopia, there are no working red cone cells. Red appears as black. Certain shades of orange, yellow, and green all appear as yellow. Protanopia is an X-linked disorder that is estimated to affect 1 percent of males.
Deuteranomaly: In males with deuteranomaly, the green cone photopigment is abnormal. Yellow and green appear redder and it is difficult to tell violet from blue. This condition is mild and doesn’t interfere with daily living. Deuteranomaly is the most common form of color blindness and is an X-linked disorder affecting 5 percent of males.
Deuteranopia: In males with deuteranopia, there are no working green cone cells. They tend to see reds as brownish-yellow and greens as beige. Deuteranopia is an X-linked disorder that affects about 1 percent of males.

Blue-Yellow Color Blindness
Blue-yellow color blindness is rarer than red-green color blindness. Blue-cone (tritan) photopigments are either missing or have limited function.

Tritanomaly: People with tritanomaly have functionally limited blue cone cells. Blue appears greener and it can be difficult to tell yellow and red from pink. Tritanomaly is extremely rare. It is an autosomal dominant disorder affecting males and females equally.
Tritanopia: People with tritanopia, also known as blue-yellow color blindness, lack blue cone cells. Blue appears green and yellow appears violet or light grey. Tritanopia is an extremely rare autosomal recessive disorder affecting males and females equally.

You could make the colors configurable (back to your high contrast checkbox idea or color themes), as long as that's something you save in a configuration file for the user (if they struggle with getting to the setting every time, it won't be as useful).

This... is kind of a nightmare with the current system. To give you an idea of how the color assignment currently happens, it's this table:

It's an arbitrary set of colors, half of which don't even have clearly assigned semantics—you can only really tell if you grep the sources (don't forget to handle indirect colors via %Fp and %Bp...) and try to infer original intent. If I were to just add some configuration options (which isn't that hard), it would be a table of colors that you change and then something somewhere else in the UI changes color as a result, with little indication of what it will be. I think that's not a very good choice for a set of configuration options, especially if one is colorblind.

Having a single checkbox that basically goes over that table with a huge hammer is at least easy to get working reliably, if the results aren't very good.

I suspect those additions would allow you to attract sponsorship for some complex things like arbitrary path extrusion, skinning, patching, and lofting, which in turn would make SolveSpace usable as a cross platform "daily driver" CAD package for a lot of people.

I think people who have that as an absolute requirement currently use FreeCAD (or, if their tolerance to proprietary software is higher, F360). It's pretty hard to convince people to sponsor work of several full-time developers focusing on a geometric kernel where they have a wide set of alternatives costing $0, some of which are FOSS.

I think the hammer is a good first step. Figuring out what color goes where is probably a task for another day, but wouldn't go amiss down the road. It could probably be handled via some documentation and a file that allowed those values to be configurable, but clearly that'd mean some refactoring since they're defined as const right now, and would have to become properties that were configured at runtime instead.

I think people who have that as an absolute requirement currently use FreeCAD (or, if their tolerance to proprietary software is higher, F360). It's pretty hard to convince people to sponsor work of several full-time developers focusing on a geometric kernel where they have a wide set of alternatives costing $0, some of which are FOSS.

My issue with FreeCAD has always been that it tries to be everything to everyone, and suffers from a lot of stuff that feels unplanned and winds up orphaned and/or lightly maintained. This may have improved, as it simply couldn't meet my needs for a long time and I have never really invested a lot of time into it. It does do certain things that are otherwise hard to find in FOSS (like FEA), but you had to create your geometry in the FEA tool to even use it when I last checked a few months ago, which seems pretty counter-intuitive. It's possible there's some way to import geometry that wasn't covered; I don't do much FEA, so I don't follow it closely. SolveSpace has the potential to be what a lot of people really need most of the time: an easy to use constraint-based CAD system with a solid construction history, that's also FOSS. I personally would be happy at least 95% of the time with a chamfer tool and a fillet tool that could handle inside and outside fillets. I think those two features would allow me to do most of my parts in SolveSpace, probably only going to Shark for special cases and for GD&T features on the very rare occasion where I have to send a part out.

My issue with FreeCAD has always been that it tries to be everything to everyone, and suffers from a lot of stuff that feels unplanned and winds up orphaned and/or lightly maintained.

Yes. That's my FreeCAD experience as well, hence why I ended up maintaining SolveSpace. But I find that people have a lot of tolerance for that, especially once they learn how expensive it is to develop a high-quality NURBS solid manipulation library.

for GD&T features on the very rare occasion where I have to send a part out.

GD&T is actually one of things that I would really like to see in SolveSpace myself, as most of my CAD work ends up in a contract shop.

@phkahler Did you delete your comment? I think l stands for "link". Anyway, with { 'l', RGBi(150, 150, 255) }, the text window looks something like this (old on left, new on right):

Overall, if the blue were replaced with cyan (for instance), I think it would help a lot

@supertaz Does the change above help enough, or should I make it even lighter? It looks quite a bit better to me, at least.

@whitequark I did delete it - low value. I find the brighter blue a lot more readable while still being blue enough to not be noticed as a colour change. If it gets too close to white we'll want to change the separators for better contrast too: show all / hide all

@whitequark it seems a bit better, but I still think it should ultimately be higher contrast, considering it's the color for the primary information in the UI and comprises a fairly significant portion of interaction with the application (outside of the draw window, this is where all the important information in the UI resides, and a very large percentage of that information is blue).

@supertaz See #446 for @phkahler's higher contrast version (that I already merged).

@whitequark The images in #446 look like a much better color than the original attempt here. It may be a few days before I have a chance to try it out, but I expect it'll be an improvement.

@supertaz Have you had a chance to try the new color scheme?