GTK 4.12 Released With Many Vulkan Backend Improvements

[phoronix]

Phoronix: GTK 4.12 Released With Many Vulkan Backend Improvements

Tagged on Saturday was GTK 4.12 as the newest version of this open-source toolkit...

https://www.phoronix.com/news/GTK-4.12-Released

[johanb]

I can see that a "GtkSectionModel" was added in 4.11.2, but can't find any pictures of how that might look in a standard GtkListView. Might be interested in using that for one of my tiny apps, anyone got any pictures of how it looks or any code examples? Can't find any example in gtk-demos.

[uid313]

I like GTK, but...

When using GTK in Python there are no type hints available, and you cannot use Python's asyncio module together with GTK. There is a third-party package called gbulb that can work around this, and there is a pull request in pygobject but is not yet merged.

When using GTK in Rust, I feel like there is boiler plate code and I need to rely on macros. I am pretty bad at Rust, but I get the impression that GTK might not be so idiomatic Rust and feel a bit shoehorned.

When using GTK you sometimes are burdened with having use GLib-specific data types instead of data types that are native to the language. For example in Rust which can already be tricky with String, &String, str, and &str, you now also have to deal with GString, &GString, gstr, &gstr, or something like that. Instead of just using the built-in bool data type, you have to deal with gbool, and such.

I like some of the new stuff such as Gtk.ColumnView, but they're also deprecating many useful widgets.

They deprecated the Gtk.ComboBoxText widget which was really easy to use to create a dropdown. My drop down had two entries in it, I could write that all that in like 3 lines of code. It is replaced by Gtk.Dropdown which requires you to create a model and a list item factory which is way overkill for my scenario which makes it much more complicated for me and I need to write a lot more code.

They also deprecated the Gtk.InfoBar widget, which was a nice way to display information, warnings and errors. They want us to implement that ourselves, but it just makes it more complicated for me, and requires more boilerplate code, then I need to repeat that code in every place I use it for it to be consistent, and other applications may have different implementations.

There is also the Adwaita dilemma. If you don't use Adwaita your application looks bad and feels alien on the GNOME desktop, but Adwaita is explicitly for the GNOME desktop, so you don't want to use it if you want your application to be used on KDE, macOS and Windows, etc.

[oleid]

I like GTK, but...

When using GTK in Rust, I feel like there is boiler plate code and I need to rely on macros. I am pretty bad at Rust, but I get the impression that GTK might not be so idiomatic Rust and feel a bit shoehorned.

no, it is not. But the same could be said about any classical object oriented toolkit. That's why there are several attempts for rust native toolkits (iced, xilem, ...).

Did you have a look at relm? It makes gtk more rusty.

When using GTK you sometimes are burdened with having use GLib-specific data types instead of data types that are native to the language. For example in Rust which can already be tricky with String, &String, str, and &str, you now also have to deal with GString, &GString, gstr, &gstr, or something like that.

It makes sense to provide different types for strings, since they guarantee different invariants. The same way as Qt users have to deal with Qstring and string in C++.

Instead of just using the built-in bool data type, you have to deal with gbool, and such.

That's strange. Where did you find the gbool? I couldn't find it in the API

https://gtk-rs.org/gtk4-rs/stable/latest/docs/gdk4/index.html?search=Gbool

There is also the Adwaita dilemma. If you don't use Adwaita your application looks bad and feels alien on the GNOME desktop, but Adwaita is explicitly for the GNOME desktop, so you don't want to use it if you want your application to be used on KDE, macOS and Windows, etc.

I didn't research the subject but I'm wondering: would it be possible to load adwaita on the fly, deepening on the platform?

[fitzie]

I like GTK, but...

When using GTK in Python there are no type hints available, and you cannot use Python's asyncio module together with GTK. There is a third-party package called gbulb that can work around this, and there is a pull request in pygobject but is not yet merged.

I was playing around with flet the other day ( https://flet.dev/docs/ ) and it shows me what pygtk could have been. It has some big issues that would prevent it from being a good front end, but wow, the api is just really nice. Honestly, not to bag on gtk, but between their call from help with python:

https://www.bassi.io/articles/2022/12/02/on-pygobject/

and them not being able to commit to supporting the major desktops:

https://www.phoronix.com/news/GTK-macOS-Back-Seat

makes me worry about gtk. Honestly, I wish gtk would just adopt libuv for the core eventloop and tack on all their glib extras on top. then integration with python would be a lot easier. Although I do hear good things about relm4 for rust (not relm, which is a different implementation of the same thing).

[QwertyChouskie]

Nobody's talking about the most exciting thing: fractional scaling! It's still disabled by default for the OpenGL back end, but should work if you enable the Vulkan back end, and I think the software rendering back end too.

Hyyyyyyyyyyyyyyyype

[QwertyChouskie]

GDK_DEBUG=gl-fractional to enable fractional scaling on the default GL back end. Might be some bugs still, caveat emptor.

[You-]

Did gtk manage to beat Qt in an actually implementation of the fractional scaling protocol that apps can use?

[AdrianBc]

Nobody's talking about the most exciting thing: fractional scaling! It's still disabled by default for the OpenGL back end, but should work if you enable the Vulkan back end, and I think the software rendering back end too.

Hyyyyyyyyyyyyyyyype

I see quite frequently here and in another places passionate claims about "fractional scaling", but I always fail to understand why anybody needs such a feature.


I have been using Linux on all my desktops and laptops for more than two decades and during the last decade I have been using almost only 4k monitors.

Since the earliest times, I never had any problems on high-resolution monitors with most applications, because for each monitor I set the right value for the "dots per inch" value, so any text that uses e.g. a 12 point font will be rendered at the same size, regardless if the monitor is high-resolution or low-resolution, even if in the latter case it will look uglier.

I had only two kinds of problems. The first is that there are some incompetent Web page designers who specify sizes in pixels, instead of using display-independent units. However, all Web browsers have had zoom with fractional values for as long as I can remember, so such Web pages could always be magnified at will.

The second problem is that there are various commercial programs that are written in Java, with the purpose of running both on Linux and on Windows, and all such programs that I have ever seen are written in a stupid way and, unlike the programs that use GTK or QT, they ignore the system settings, so they render their fonts at wrong sizes that are too small. For such badly behaved programs it is useful to be able to enforce a scaling of their window. Nevertheless, such programs have to be run very infrequently and for a short time, e.g. they may be the installers for some professional programs, so just having a means for double scaling is enough to deal with them.

I can imagine that someone might have some icons that have been made in one size with a fixed number of pixels and it may be desired to increase their size by an arbitrary factor, but that can be done with any image editing program, and then the modified icons can be used to replace the original icons. No fractional scaling in GTK is needed for this.


So I am puzzled about which is the intended use for "fractional scaling" as a feature of GTK, because I have not seen yet a need for it, despite my exclusive use of high resolution monitors on Linux (with XFCE, but I use both GTK and KDE based programs).

[QwertyChouskie]

I see quite frequently here and in another places passionate claims about "fractional scaling", but I always fail to understand why anybody needs such a feature.


I have been using Linux on all my desktops and laptops for more than two decades and during the last decade I have been using almost only 4k monitors.

Since the earliest times, I never had any problems on high-resolution monitors with most applications, because for each monitor I set the right value for the "dots per inch" value, so any text that uses e.g. a 12 point font will be rendered at the same size, regardless if the monitor is high-resolution or low-resolution, even if in the latter case it will look uglier.

I had only two kinds of problems. The first is that there are some incompetent Web page designers who specify sizes in pixels, instead of using display-independent units. However, all Web browsers have had zoom with fractional values for as long as I can remember, so such Web pages could always be magnified at will.

The second problem is that there are various commercial programs that are written in Java, with the purpose of running both on Linux and on Windows, and all such programs that I have ever seen are written in a stupid way and, unlike the programs that use GTK or QT, they ignore the system settings, so they render their fonts at wrong sizes that are too small. For such badly behaved programs it is useful to be able to enforce a scaling of their window. Nevertheless, such programs have to be run very infrequently and for a short time, e.g. they may be the installers for some professional programs, so just having a means for double scaling is enough to deal with them.

I can imagine that someone might have some icons that have been made in one size with a fixed number of pixels and it may be desired to increase their size by an arbitrary factor, but that can be done with any image editing program, and then the modified icons can be used to replace the original icons. No fractional scaling in GTK is needed for this.


So I am puzzled about which is the intended use for "fractional scaling" as a feature of GTK, because I have not seen yet a need for it, despite my exclusive use of high resolution monitors on Linux (with XFCE, but I use both GTK and KDE based programs).

Most likely the PPI of your monitors just so happened to work out so that everything is at just about the right size at a 2x scale. Integer scaling has been supported for years out-of-the-box.

If you have, for example, a 15 inch laptop with a 1440p screen (which is actually a really good sweet spot for good sharpness without being too hard for the GPU to drive), then 100% scaling is way to small, and 200% is way too big. If your system needs e.g. a 150% scale, and you try to just change the font scale rather than the whole scale, things get wonky, as you are trying to squish big fonts into small boxes/buttons/etc.

(Even 1080p at 14" makes things a tad too small, though it's close enough that just increasing the font scale to 1.2x works fine in my case.)

TL;DR: Fractional scaling often isn't needed for very high DPI (e.g. 4k), but is absolutely vital for medium-high DPI (e.g. 15" 1440p laptop displays).