Big facts.

Do we have a roadmap for porting to GTK4?
#3306 took care of some preparations. What should the next steps be?

We should probably start by adding a CMake option that lets us choose GTK4 and then see what compiler errors we get. I imagine that there will probably be a lot of places where we will need to make changes.

On another note, Glade does not seem to support GTK4. We will need to switch to another API like GtkBuilder.

Oh, it appears that we already use GtkBuilder internally; Glade is only used to edit the .glade files. So as far as "switching from Glade" is concerned, I think the only required change is to port the .glade files over to the GTK4 builder format.

I think a big source of troubles will be the input handling: https://docs.gtk.org/gtk4/migrating-3to4.html#stop-using-gtkwidget-event-signals. Most of the GTK4 replacements for deprecated GTK3 signals have been backported to GTK3, so we can start making changes without actually making the switch just yet.

@Febbe You had worked a lot on this on a dedicated gtk4 branch. It's not quit clear to me what part of this branch was merged with #3306 and what was not.
I could try and help on this front if you want

The complete gtk4 branch is not part of the current master. It must be rebased. And I would cherry pick small fixes which are compatible to gtk3. One of the problematic changes is the whole dialog systems. Dialogs do not have a run function anymore and are non blocking now.

Therefore it might be useful to replace those by cpp20 coroutines. This would reduce the effort to rewrite all Dialogs.

The next big problem is, that gtk4 dropped menu's so we have to switch from gtkmenu to gmenu which is only declarative. Every menu in xpp must be reworked.

Last but not least GTK integrated some sort of Inputhandling like we implemented it. But now, when we adapt the input system as is, it's like shooting drills with a Canon on a wall to make holes.

@bhennion, help is appreciated, currently I have few resources. Therefore, it would be good if someone takes over the branch.

I'll have a look. The rebasing seems hellish though

One of the problematic changes is the whole dialog systems. Dialogs do not have a run function anymore and are non blocking now.

Can't we just use modal dialogs like

    GtkWidget* dialog =
            gtk_message_dialog_new(nullptr, GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, "%s", msg.c_str());

and replace:

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);

by

    g_signal_connect(dialog, "response", G_CALLBACK(gtk_widget_destroy), NULL);
    gtk_widget_show(dialog);

and after the switch replace gtk_widget_destroy by gtk_window_destroy?
See https://docs.gtk.org/gtk4/migrating-3to4.html#reduce-the-use-of-gtk_widget_destroy

That only works, when every call to one of our Dialogs emediately returns into the event queue.

And the most of them are waiting for response.

The other solution, which would keep the previous behavior, is to remove all return values from functions and strictly use callbacks. Also every function musst be split up at the call to an dialog.

Since this is a lot of effort, I proposed the idea of the coroutines. With them the controll flow stays the same for the function. We only have to call co_await, when calling an dialog and co_return instead of return.
An coroutine Eventhandler must be created, which calls and resumes them and we must create a wrapper around Dialogs, so we can await them.

I'll have a look. The rebasing seems hellish though

@bhennion yes, rebasing is hell at this point. Therefore it might be better to pick small pieces , where you only copy the changed code.

Like: the menubar must be replaced by GMenu. Since this is a change we should have done after GTK2, this can be made without a change to GTK4.

Like: the menubar must be replaced by GMenu. Since this is a change we should have done after GTK2, this can be made without a change to GTK3.

Ok. I gave this a look. This is a well identified task (quite cumbersome as well!). I'll give it a try.

Like: the menubar must be replaced by GMenu. Since this is a change we should have done after GTK2, this can be made without a change to GTK3.

Ok. I gave this a look. This is a well identified task (quite cumbersome as well!). I'll give it a try.

I already started this task in the gtk4 branch, but it was not complete, since my priority was to get the compilation working first. This had the drawback, that I commented out lot of the code, instead of porting it.

For later, there are other GTK classes that disappeared in GTK4 (on top of what's listed in #3306 (comment))

• Remove GtkToobar and GtkToolItem
• Remove GtkMenu and co.
• Remove GtkLayout

And more to come in later edits

See #4561 for a discussion of the redesign with Gtk 4 / libadwaita.

Here is a list of the gtk3 functions used in the code and which are retired in gtk4:
gtk3-uses.txt

There are false positives in there (e.g. if in a #if GTK_MAJOR_VERSION == 3) but it may help see what's left to do.