Channel mode buttons do not respect GTK+ system font

[vaygr]

For some reason system-wide GTK+ font is not reflected on channel mode buttons, like c, n, t, i, etc.

Instead, it falls back to some kind of Sans:

I checked all possible variations including both TTF and bitmap fonts. The rest of the interface works just fine though.

HexChat version 2.12.4.

[TingPing]

They are hardcoded to monospace so each button is the same width. I think you should just set the system monospace font to what you want.

[vaygr]

Ah, I'm not sure I'd be able to do so, because all other applications (like web-browsers) depend on fontconfig and do not correlate with GTK+ settings.

I use over 15 different fonts on my system, but here I couldn't find an option to apply a monospace font just for GTK+ widgets, because there's only one setting I found font_name, and it's already there.

So here I simply cannot switch my "default monospace font" from TTF to the bitmap one, because the rest of the system would be switched to it too, which is not something I would wish to do.

[TingPing]

This is purely a fontconfig setting, what monospace resolves to.

[vaygr]

Yes, that's what I'm saying. If I override it in fontconfig, it's going to be set everywhere system-wide, but I just want to change it for GTK+ widgets, which already use the font I wanted them to use.

[vaygr]

I've found out where it originally came from.

The bad thing is that you cannot control Pango markup format from your GTK+2 theme, so any font that doesn't have a monospace face will be rejected and will result to the interface look'n'feel inconsistency.

So maybe there's a chance to make that <tt/> hardcoding optional?

[TingPing]

I don't see any reason to, if you don't like your monospace font you change it.

[vaygr]

Well, the problem is that I want to keep my default monospace font for the rest of the system intact, while making GTK+2 applications use a theme with configurable font. That's because browsers, DE/WM themes and GTK+2/3 themes have almost nothing in common.

So as one of the comment from the URL above states:

It is generally considered bad form to do that; apps should respect the user's theme.

[vaygr]

I think a better solution for the original issue would be a dynamic width calculation based on font properties. To make sure fitting problem doesn't happen again, we could use this analysis that says W is probably the widest character statistically in the most of fonts, so we could pick it as a golden standard to make all buttons have the same width.

This is the patch last night I came with and added to hexchat package in our distro.

Here's what it does:

1. Creates a label with just W symbol
2. Calculates its dimensions
3. Immediately destroys the no longer needed "testing" widget
4. Uses the value of width to set widget size and adds 5px padding from left and right sides

I'm pretty sure there should be ways to optimize it and partially re-implement the idea, but that's just the first draft. Tested it on several TTF/bitmap fonts with different sizes.

This would not lock users out of strict font choice, and would keep the interface consistent if GTK+ font/theme is different from the system-wide font setting even if the chosen font didn't have monospace face.