What are the best practices for resolution independent / responsive UI design with GTK/gtkmm?

Platform
,
1

Full disclosure: I posted the following already on StackOverflow last week, but received no views or answers, so I am hoping I will have better luck here and nobody minds me reposting this. Thanks!

I understand that in GTK >= 3.x all metrics are in logical pixels which will be scaled by a given scale factor (e.g. env var GDK_SCALE), resulting in the actual physical pixel metrics. Unfortunately the scale factor is an integer and as such rather coarse, frequently not really fitting the given combination of screen resolution and physical screen size-- resulting in an UI that is either too large or still too small.

There is also the possibility to combine said scale factor with mere font scaling (e.g. env var GDK_DPI_SCALE) which is a fractional number. This can help to a certain extend but non-text UI elements like icons and such, will still be either too large or too small.

GTK also offers certain CSS styling features-- amongst others, metrics in different units than logical pixels like (r)em (which is based on the user’s font size). At the very least, using CSS to style the UI does add further complexity to the code and I am unsure if this is actually the recommended approach or is more targeted for developing GTK themes.

Personally, I have a 4k 27" screen, which is problematic with GTK since I cannot set the proper scale factor. So, developing a GTK app that also looks nice on all sorts of other screens, is not the easiest thing to do.

So, back to my question: Are there recommended best practices for developing resolution independent / responsive UIs with GTK/gtkmm? Should one lean towards using CSS for setting metrics and stay away from doing it through the API in logical pixels? Or is this a use-case that is not actually covered by GTK and one should simply set arbitrary pixel values for margins and such, and hope for the best that it works with other (Hi)DPI screens as well?

Thanks for any tips and hints in advance.

1 Like
2

I too, and I think that is not the best combination. Some years ago, larger ones were too expensive, but I think my next one will be 32 inch, which will make life easier.

I understand that in GTK >= 3.x all metrics are in logical pixels

I am not even sure about that: I think some Pango font sizes are in Points, that is 1/72 inch. If I remember correctly, Point size was used in LaTeX too, and it made some sense. For Gnome, actually, when I use a a font tool to modify the text size, I am not even sure if I adjust point size or pixels.

Twenty years ago, life was easy, we had 15 or 17 inch monitors, with pixel sizes of about 0.25 mm. Today we have so much freedom. HiRes displays with tiny pixels, nearly invisible, and large Screens with diagonals of more than 2 meter. So we have to realize, that the real variable is the viewing angle: A screen with 1m diagonal and 0.2 mm pixels looks from 1m distance the same as a screen with 2m diagonal and 0.4 mm pixels from 2m distance.

Size scaling is really not easy when we create CAD like apps, and one additional issue is, how text annotations should behave when the user enlarge a window or zooms in. I think, we need at least two text variants, one that increases when we zoom in, and vanishes when we zoom out a lot, like annotations attached to objects. E.g. pad numbers on PCB boards, or pin labels on schematics. And other text, like sheet name, author name, date and such. I think that data should have a fixed size in points, and should not shrink for zooming out. This sizing is one of the largest issue for my CAD like tool from GitHub - StefanSalewski/SDT: A simple Nim GTK4 drawing and design tool

Recently I heard that latest wayland may support fractional scaling – I really wonder how that may work, how will a 1.5 pixel width horizontal or vertical line be created? With high screen refresh rate, 120 Hz or more, and alternating between one and two pixel, like in old television days?

3

Regarding the original question of this post: Seems like there really is not much guidance on how to address the issue of Lo/HiDPI screens with regards to GUI design. I would have hoped to get a bit more feedback… or anything really. I guess I will keep testing with CSS and other techniques and see what, at the end, best fits my own needs. Sigh.

Absolutely agree. The problem though: The monitor market is rather stagnant and mostly geared towards gamers. There is really no meaningful advancement/improvement in terms of panel quality (as-in: visual, not speed). If you want a screen with deep blacks (not greyish mist) and high contrast as well as good viewing angles, no or little IPS/VA glow, no VA gamma shift, no black crush and absolutely no image retention, you will certainly have a very hard time finding that.

My current monitor has very (!) bad image retention which is driving me insane and I have been keeping a very close eye on the market for ages, trying to find a 32" replacement that at least meets some of the above requirements (and has no image retention!)… but thus far, nothing. The LG IPS black panels sound nice, but there are only a few monitors available and the first generation does not improve on all fronts, misses out on others and well…

Finding a new monitor has never been this hard, imho.

AFAIR Pango allows both, setting sizes in points and pixels.

Actually, I have been following the discussion of that protocol-- and naturally there was a lot about exactly that issue. Before I say something wrong, I will keep my mouth shut and refer you to the actual merge request where everything was discussed in great detail. :slight_smile:

By the way, Jetpack Compose (Android’s newest UI toolkit), is, imho, really nice to work with and as a unit it uses device-independent pixels. You still have to put some thought into the design if you want to make reasonable use of all available space (and adapt properly to changes), but again… nice to use. But that’s Android… though, not of great help here.

1 Like
4

The answer is: no, not really. Especially with GTK3, since it’s an API and feature frozen toolkit, which means that any future improvement will not be backported as it will end up impacting the API.

CSS is also a red herring: GTK’s CSS has the same limitations as GTK’s API, as they were both written when scaling factors had been introduced in the general desktop computing world.

In practice, you should always consider the scaling factor as an integer; compositors on Wayland can scale down your UI to a fractional value between 1 and 2. If at some point scaling will be available with fractional values, you (or the toolkit) will still need to align every UI element to the pixel grid anyway, except when animating between states (and possibly not when animating text).

Correct.

5

I was afraid of that. It makes GUI design a tough nut to crack, especially if you do it on a 4k 27" screen which is not the best fit for GTK anyways.

I am using the latest GTK-4/gtkmm-4.

I see my error in thinking. Even though it allows to use (r)em units and such, so you should be able to design a UI that somewhat adapts to the screen dpi, the resulting pixel values will still get scaled depending on the environment (e.g. compositor, GDK env vars and such). That makes this CSS approach even counter productive in the end.

Thanks a lot for clearing that up. May I ask if there are any significant and helpful changes planned in GTK in that specific area?

6

Not at the moment. Even with the new Wayland protocol, the scaling factor is exposed in the GTK API as an integer, which means we cannot change anything there until we bump to the next major version.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.