Migration to Gtk4 for Linux

[MuhammadMuradG]

Is there a plan to migrate to GTK4?

The current implementation is based on GTK3, which is working but would require significant changes to comply with the new Human Interface Guidelines (HIG).

Unfortunately, these changes would be invalidated when the migration to GTK4 takes place.

As a quick example, some method of HeaderBar doesn't exist in Gtk3 or Gtk4.

[freakboy3742]

We're definitely aware that GTK4 exists, and that a migration will need to happen at some point. However, at present, we don't have any specific plans to perform a migration.

If I had to guess, the most likely approach to the migration would be to leverage the work we're currently doing with the widget audit. We're currently working through each widget in turn, auditing the API and implementation, and building test harnesses for the GUI aspects so that we can get to 100% test coverage for every widget. Our aim is to get to 100% coverage of widgets by mid-year. Once that test coverage in place, we'll be in a much better place to do a large scale migration, because the acceptance criteria for a GTK4 port becomes "does the test suite pass?", rather than a need for detailed hand audit of every feature in the GTK backend.

If someone (cough... you? :-) ) is up for a long-term project, one approach might be to open a draft GTK4 branch, and shadow the work the core team is doing on the widget audit. At present, that means you'd only need to port 9 widgets to GTK4 (ActivityIndicator, Button, Divider, Label, ProgressBar, Slider, Switch, Box and the base Widget), plus presumably some core infrastructure around the app and window objects. This branch wouldn't be merged quickly - it would be an ongoing project that is periodically merged with the main branch as the audit of individual widgets is completed. Once the widget audit is complete, the GTK4 branch should be ready to perform a wholesale switch, with full test coverage.

That said - I won't profess to being a GTK expert; my understanding is that GTK4 is a "backwards incompatible specifics, but fundamentally compatible at a conceptual level" migration. There might be a bunch of API changes that are required, some new capabilities that become available, and some options that we won't have access to until we migrate - but fundamentally, GTK4 "tastes" about the same as GTK3. If that's not the case, and the move to GTK4 will require some more radical changes, then maybe we would be better served migrating before we audit a bunch of widgets with the GTK3 API. Are you in a position to provide any guidance on this?

[MuhammadMuradG]

That said - I won't profess to being a GTK expert; my understanding is that GTK4 is a "backwards incompatible specifics, but fundamentally compatible at a conceptual level" migration. There might be a bunch of API changes that are required, some new capabilities that become available, and some options that we won't have access to until we migrate - but fundamentally, GTK4 "tastes" about the same as GTK3.

It seems that, but I am not sure.

If that's not the case, and the move to GTK4 will require some more radical changes, then maybe we would be better served migrating before we audit a bunch of widgets with the GTK3 API.

I quickly investigated some widgets, and found that some of them are missing important properties that are used in layout. For example, the Gtk.Button widget doesn't have a get_preferred_width() method. Also, some widgets are no longer a subclass of classes, which their properties are used in layout, like the Gtk.Fixed widget isn't a subclass of the Gtk.Container class. Additionally, some classes no longer exist, such as the Gtk.Alignment class.

Are you in a position to provide any guidance on this?

Does the previous help?

Useful Ref:
Gtk3, Gdk3
Gtk4, Gdk4

[freakboy3742]

If that's not the case, and the move to GTK4 will require some more radical changes, then maybe we would be better served migrating before we audit a bunch of widgets with the GTK3 API.

I quickly investigated some widgets, and found that some of them are missing important properties that are used in layout. For example, the Gtk.Button widget doesn't have a get_preferred_width() method. Also, some widgets are no longer a subclass of classes, which their properties are used in layout, like the Gtk.Fixed widget isn't a subclass of the Gtk.Container class. Additionally, some classes no longer exist, such as the Gtk.Alignment class.

Ok - those two sound fairly major. The specific API used to get the size of the widget isn't critical, and the use of Gtk.Fixed as a container isn't critical either. get_preferred_width() and Gtk.Fixed work for GTK3, so we use them, If GTK4 has different APIs for these, that's fine - but we do need to be able to take complete control over the layout process so we can position widgets according to Pack, and we also need to know the minimum rendered size of a widget so that we can feed that detail into Pack to generate a rendering.

Are you in a position to provide any guidance on this?

Does the previous help?

It's a good initial investigation; I guess someone will need to dig deeper to find a solution.

Useful Ref: Gtk3, Gdk3 Gtk4, Gdk4

I mean, sure - I also can use Google to find the docs online :-) That doesn't really help identify where the migration problems will lie.

[MuhammadMuradG]

Ok - those two sound fairly major. The specific API used to get the size of the widget isn't critical, and the use of Gtk.Fixed as a container isn't critical either. get_preferred_width() and Gtk.Fixed work for GTK3, so we use them, If GTK4 has different APIs for these, that's fine - but we do need to be able to take complete control over the layout process so we can position widgets according to Pack, and we also need to know the minimum rendered size of a widget so that we can feed that detail into Pack to generate a rendering.

Yes, extra investigation required to understand how layout work in GTK4, but I think it is simple.

It's a good initial investigation; I guess someone will need to dig deeper to find a solution.

I have a passion to do that but unfortunately I have a limited time to do it now. I will put it at on my priorities.

I mean, sure - I also can use Google to find the docs online :-) That doesn't really help identify where the migration problems will lie.

I know 😄, I putted them for ease of access, why I need to search again on Google to find them if I did it before! Now I just need a one click; a one click is easier than search on Google 😄, I need my RAM for other things other than dozens of Tabs.