GTK4 migration

[dlbeswick]

The Clutter project is retired, and it recommends users migrate to GTK4: https://blogs.gnome.org/clutter/2022/02/16/retiring-clutter/

There are quite a few little GTK Criticals that pop up when running under Wayland under GTK3, which is annoying while debugging, so I figure it's a good a time as any to give the migration a go.

FYI I've begun some work in this branch in my repo: https://github.com/dlbeswick/buzztrax/tree/feature/gtk4

[dlbeswick]

Initial impressions:

• GTK4 favours widget composition over inheritance, and many GTK3 classes are now final when they weren't before. This is generally a good thing, I think, but there's quite a bit of migration work in switching away from these derived widget classes.
• It is now much easier to create custom widgets just by subclassing GtkWidget and using composition.
• Migrating combo boxes, list views and column views is a huge pain, but the new GTK4 abstractions make sense.
• GTK4's Builders (.ui files), although a little cryptic at first, could help with simplifying the code and removing a lot of widget creation boilerplate.
• No longer needing to use Clutter will make things easier and help to simplify the interactions between GTK and Clutter during event handling.
• Input handling has changed quite a lot, with Gestures and Event Controllers taking the place of many input signals.
• GTK4's focus on using Actions for menu commands, while sometimes awkward while migrating the code, is actually pretty cool and could enable a low-effort way of sending commands to active Buzztrax processes (over DBus, for example.)
• I have started using Adwaita (GTK4 GNOME "design language" library) as well.
• The migration will smooth the path to running Buzztrax on other devices like tablets, one fine day.
• GtkDialogs are replaced with GtkWindows or AdwWindows.

[ensonic]

Wow, thanks for the initial analysis. The main use of clutter is the machine view and for that we'd need our own widget. I've ported that in the past from gnome canvas back then everyone told me clutter is the future :/

I think the best approach would be to start a gtk4 branch and keep hacking until it works. I can try to help a bit, if you can take the lead on organizing a migration plan (e.g. if you have smaller tasks to offload).

[dlbeswick]

Great idea, thanks! I'll get something compiling and running in whatever state, get the branch into the main repo here, then I'll make a bunch of suggested tasks and we can go from there.

[dlbeswick]

Just an update here, finally the code compiles. This is a massive job; I have been working pretty solidly on this for at least a few hours each day. I might just take another week to make sure that something reasonable appears on the screen.

I'm not sure I've made the best choices here in all areas, but I'm in it for the long haul.

I should also say that I'm happy to revert any and all of whatever I've done that's not "necessary" if you don't like it.

Things I've been doing that I needed to do:

• Trying to migrate code relating to style contexts. The code around styling seems to have changed a lot, and I'm guessing it hinges much more heavily on CSS. See also this: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/method.Application.get_style_manager.html. There will still be quite a lot of work here to figure out the best GTK4 way to do things. Maybe it doesn't matter so much as you'd like to take a fresh eye over the app style, anyway.
• Updating option handling code, which has changed a little around GtkApplication in 4. GTK also now provides some "standardised" option handling around file opening, which it would probably be a good idea to conform to.
• Changing popup menu item and toolbar menu callbacks to Actions and GMenus. There's no other way to do this now. In some cases, I've been moving handling logic out of UI controls and into places like the EditApplication; this should technically be a good thing as if I've done it right, the logic will move closer to the class actually responsible for it.
• Moving all menu bars and GtkPopupMenus to use GtkPopover-derived classes.
• Migrating Toolbar-type code, as GTK no longer has them. The closest thing in Adwaita is now this, which looks quite nice: https://gnome.pages.gitlab.gnome.org/libadwaita/doc/1-latest/class.ToolbarView.html
• As mentioned, for custom widgets, moving to composition-based approaches rather than inheritance. The approach is still a bit all over the place as I tried different things to see what worked best. Sometime I derived from GtkBox (which is still possible,) sometimes I just use a regular GtkWidget.
• Replacing custom draw functions with GtkDrawingAreas or GtkWidgets with a snaphot override.
• Migrating code around GtkBox packing and scrolled windows. GTK4 does it a little differently; in some cases it's just a change of function name, in other cases the way to use the widget has changed.

Things I've been doing that I didn't need to do:

• Changing a lot of the classes to Final, unless they were already subclassed or things that are typically likely to be subclassed. I just thought it cut down on some of the boilerplate.
• Using UI builder XML files. Still not sure whether this will be a win or not; one annoying thing is that GTK is not giving me the line number of any errors it finds while parsing the files. It can also be a bit mysterious trying to dig up how to express things in builder format; the docs are often quite sparse. But, the code does feel a bit nicer so far, it feels that a lot of the widget creation code goes away and we can focus on the widget behaviours. Also layout changes should be easier.

Things I probably shouldn't have done:

• Updating all the "deprecated" code I saw, just because it will be removed in GTK5. I should have left GtkTreeView alone, I should have left GtkDialog alone, etc... if my choice to do this causes the migration to drag on, it might seriously be better to take a step back, revert all those changes, and go back to using the deprecated classes.
• Changing deprecated message dialog handling code to use GTK's new "async" style of callback for these methods.

Things that will still need to be done:

• I haven't found a good replacement for the old file browser widget, yet, and some of its functionality that Buzztrax is using seems to have been gone for good. I'm thinking about the wave file browser widget, for example. We might need to do a bit of work here in spinning up a new widget.

Good things:

• The new ListView replacement should hopefully be a win, despite the effort. ListViews create UI controls for its items lazily, which makes them efficient and scalable.
• ListView/ColumnView also allows us to remove some classes that were purely used as models for GtkTreeView and go directly to the Core models themselves, such as the Waves list. GIO provides a GListModel abstraction that's independent of any UI code; this is quite nice.

[ensonic]

Wow, thats a log of good progress. I'll checkout the branch this week (if you could share it) and give it a go.

So far i've been not a bit fan of e.g. BUIld XML files. gtk tried various approaches in the past and it never fully worked. Hence I am curious how it looks now. That said building them in code and trying to leave logic out also requires discipline.

[dlbeswick]

@ensonic I think it's time for the birthing pains to start... I've pushed to the feature/gtk4 branch in this repo.

This is more of a sketch than a program, currently. It compiles and runs, and exits with one warning, but the only thing that works is the CPU load meter (hooray!)

For example, I've written a bunch of code which I think might point to a way to draw the machines without Clutter, but it doesn't actually work yet.

I'll start making some tasks that should keep everyone busy for a while.

[dlbeswick]

That should do for now... Also, I've placed /// GTK4 all around the code whenever I came across something that I wasn't sure about or wanted to defer to later. So, the last step of this task will be searching for all of these.

I should have documented more of them with the reason why I was deferring, but I guess I didn't think there would be so many! I'll try and do a pass over these and add some more info.