[Request]: Better adapt to large window sizes

[Kekun]

Describe the request

I have a desktop with a 27" screen and Tuba doesn't work great when maximized on it, it has a single column with a fixed narrow width which is great, but that column feels very small, hard to read, and is surrounded by void. Some other apps do something I like a lot: they don't break the structure of their UI but they render everything a tiny bit larger, maybe just at 125% or 150%.

To support this you want to scale absolutely everything: the spacing between the elements, the rounded corners, the font size, the line height, the borders… everything. GTK isn't well suited for that so I can understand how that would complexify the UI's code a lot (especially the CSS) and it's easy to forget to scale elements. The apps that support this don't have to think about many elements, so it's easier for them to achieve, also they often use a WebKitWebView. I wonder if programmatic fractional scaling of only some elements of the UI is a feature that would make sense for future versions of GTK…

I'm not 100% sure this follows the GNOME HIG, but if not then I think the HIG should evolve to include it.

Some screenshots of Tuba and Apostrophe at different sizes to explicit what I mean.

Implementation Details

• This follows the GNOME HIG.

[GeopJr]

You are aware of the state of fractional scaling, especially on the old GL (which Tuba uses), so I don't think any sort of fractional scaling is appropriate for this

The trick with Apostrophe is that since it's just a textview(-esque), it can just increase the font size. Which is something we could do too!

We can:

1. Modify the clamp values so it fills the window a bit better, width-wise
2. Automatically enable the larger font option when maximized or the window size gets larger than a certain value

My problem with font sizing however is that we can either use named values or handle everything ourselves. When I added the larger font size setting, it created an accessibility nightmare, because I had set the normal font to a certain value and the larger one to a slightly increased one. That caused issues with the 'larger text' accessibility option and custom font size settings. The solution was to use named values, small, larger... the alternative would be to get the font size on start and calculate the other values based on that.

So if we do the 'automatically enable the larger font option', it would change the font size from normal to larger, which might be a bit too big and drastically different 🤷

What do you think?

[Kekun]

• I think the clamp value is good as-is: longer lines would just be harder to read.
• Larger text is good, but ideally you'd want everything to scale up (as I said, I know it's not easy to implement cleanly with GTK).
• It shouldn't be based on the maximized state but on the window's size: you can be maximized on a small screen or have a very large floating window.
• IMO it shouldn't be tied to the larger font option as you'd want the text to be even larger if the larger font option is enabled and the window is large.

That being said, maybe your last proposition to rework how the various sizes work can make sense, also maybe I'm overthinking it: we don't necessarily have to scale everything in the thread, maybe just the message's text, and adjust the column's width accordingly (maybe relying on GtkLabel::width-chars and GtkLabel::max-width-chars)?

I know it's not something easy to implement as-is so frankly I'm not asking you to do anything about it, that's why I reported it as a feature and not an issue: it's more of an item in my dream wishlist that something I expect anybody to work on. Maybe just a place to think about what could be done…

[nekohayo]

I would guess this would be related to #118 and #215, if I'm not mistaken :)

[GeopJr]

Probably not, this is more about the UI size - without changing the layout at all.

FWIW, anything that has to do with label properties is a no-go ❌ due to this bug https://gitlab.gnome.org/GNOME/gtk/-/issues/6637