New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GTK4 preparation #2722
Comments
Big facts. |
Do we have a roadmap for porting to GTK4? |
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 |
Oh, it appears that we already use |
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. |
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 |
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 |
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. |
@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. |
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))
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: 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. |
GTK 4 was released last month and will probably become widely available over the next year or two. There's no rush to port to GTK 4 given the huge number of important issues in our issue tracker, but it would be nice to at least replace the deprecated GTK 3 parts that we can right now.
At least one low-hanging fruit I know of is the
gtk_pointer_grab
deprecation warning (or something along those lines) that's been around for over a year.This issue is very low priority.
The text was updated successfully, but these errors were encountered: