Look into using OS-provided fonts as default rather than vendoring DejaVu Sans and using it everywhere

[GyrosGeier]

It looks as if the preferences dialog would be capable of scanning /usr/share/fonts recursively, and finding the fonts in a distribution package (e.g. below /usr/share/fonts/truetype/dejavu), however if /usr/share/ngscopeclient/fonts does not exist, we don't even get to open the preferences dialog, the program immediately fails with a cryptic error message

Warning: Could not find font file "" requested in preferences database. Using default font "" instead
[00000] While loading ''
[00000] [imgui-error] (current settings: Assert=1, Log=1, Tooltip=1)
[00000] [imgui-error] In window 'NULL': Could not load font file!
ngscopeclient: ./src/imgui/imgui_draw.cpp:3142: ImFont* ImFontAtlas::AddFontFromFileTTF(const char*, float, const ImFontConfig*, const ImWchar*): Assertion `(0) && "Could not load font file!"' failed.
Aborted

[azonenberg]

Yes, we currently ship a couple of fonts to ensure sane defaults cross platform.

The long term plan is to rework this in some way and use standard OS defaults that we are confident will always be available. It's not actually the preference dialog that's the problem it's the default values for prefs (i.e. the stock theme before the user tweaks anything).

I'll flag this as a portability issue for the long term; near term bundling a font we know we can depend on even if it's already in /usr/share/fonts on some distros was the easiest solution. Probably not going to have time to touch it until 0.3 or so.

[azonenberg]

On Windows, I think Arial is a pretty safe bet although ideally we should call some OS function to figure out what the user's currently selected UI theme font is.

On MacOS I have no idea.

On Linux I assume there's some kind of setting specified by freedesktop for the user's chosen theme font?

[GyrosGeier]

The main problem is that it's an assertion failure, so the program just exits, and doesn't even allow me to create a configuration.

[azonenberg]

The main problem is that it's an assertion failure, so the program just exits, and doesn't even allow me to create a configuration.

If we get to this point things have gone wrong at several levels: the user's provided preference file didn't exist or had an invalid font path, then we fell back to the default font selected by the application, then THAT didn't work.

Aborting at this point is the only reasonable course of action, since we can't display a meaningful UI without fonts.

The proper course of action here is simply to add better platform-specific font search code, including some fallback so that we can guarantee we will always find some font.

Out of curiosity, how did you encounter this situation? Were you trying to remove the vendored font from the deb package? Because that's not going to work until we add a lot more platform-specific font searching code; vendoring it was the short term solution to "we can guarantee this ttf file will be available no matter what".

[GyrosGeier]

Yes, I removed that font because policy (replaced it with a symlink since), then did a first-time start with no preferences file in the user home.

[azonenberg]

So with the symlink it's happy and works as expected? (I haven't tested, but the current code should work with one).

Sounds like the near term issue is solved but we'll keep this ticket open. I've wanted to switch to platform default fonts to make the UI feel more "native" anyway, it's just nontrivial to do since we're not using something like GTK that does all of this for you.