View font does not fallback to default if missing

[jonpalmisc]

If you configure your view font to a font that isn't installed (or in my case, copy your settings to a new machine without the configured font), the view font becomes the default system font and comedy ensues. The font should fall back to the default mono font if the configured font is missing.

Binary Ninja 3.4.4271 (Stable)

[fuzyll]

I believe I've got this taken care of in the upcoming 3.5.4481-dev build that will hopefully make it through CI in the next ~30 minutes. This is currently implemented by looking for an exact match to what's in user settings and, if it doesn't exist, substituting our default as a fallback.

It's possible there's an edge-case that this doesn't cover, but I tested that it worked when putting nonsense in as font names in settings, so feel free to re-open if there's a situation I've missed.

[fuzyll]

Reopening this as it appears I did introduce a problem where certain fonts can no longer be set as per the issue above.

[fuzyll]

So, as far as I'm aware, the way you're supposed to do this in Qt is by calling exactMatch on the QFont. My understanding is that this will check the underlying font database to see if a font that matches exists. If it doesn't, it'll return the 'closest' font that matches the "style hint" that's been set.

I attempted to fix this by using exactMatch to detect the failing case and falling back to our default fonts if they don't. Unfortunately, exactMatch appears to just return false for everything. I missed this because I didn't adequately test for the case where we want to replace the default font and it's a valid font. I believe this is the Qt bug I'm running into, which is closed despite multiple people reporting having the same issue for the past year and a half and across both Qt5 and Qt6.

I've reimplemented this by just setting the "style hint" for the monospaced font so that it at least chooses a monospaced replacement. This isn't as nice as choosing the default font as a fallback, but it at least lets me close this issue as the view font should look appropriate now.

Should be resolved again in builds >= 3.5.4496-dev.