Enhancement: GTK4 support (Issue #23415)
Hamish Mcintyre-Bhatty
Description
It would be good if GTK4 could be supported in future. I know this is a big endeavour and may not happen anytime soon, but I thought I might as well file an issue for it for tracking.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ian McInerney
I don't think a general issue like this is useful for development (and that was also said in #22609). IMO, it would make sense to open issues based on specific parts of the code that must be changed/modernized to support GTK4. If they can be done with the GTK3 API as well, then that is nice and contained to test, and doesn't require fixing the entire library.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Hamish Mcintyre-Bhatty
Fair enough, my apologies, happy to close if you like.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
We can keep it open and try to at least collect the list of things that need to be done for GTK 4 support here. But the main problem is that I really have no idea who will have both the competence, time and motivation to work on this. Any help would, of course, be very welcome.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Hamish Mcintyre-Bhatty
I don't know any GTK so I'm unlikely to be much help, unfortunately.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
MetalPlateMage
I'm familiar with it. Not sure how it applies to wxWidgets, but the main things that will take some work are:
- Removal of GtkToolbar. You'll see this a lot as the gnome devs believe stuff like this are outdated "nonsense". Technically there's the toolbar class but..
- Menus were redone as they were seen as "X11 wrappers" and moved over to the popup model. It's sort of a paradigm shift and I'm not really sure how you'd adjust it to the wx model where menus are derived from each other. Maybe it is easier than I'm making it to be
- Removal of abstract interfaces like GtkBin and GtkContainer. I'm assuming this means you'd just have implement more derived virtual functions to handle each specific control
- The other major thing is there is a lot of stuff that is technically still available but heavily depreciated
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Avery King
Hello! I've learned that most of the current GTK port would need to be rewritten in order to support GTK 4 from here. To me this is unfortunate news, but I have an idea: what if we made a separate port for GTK 4? Maybe wxGTK4? (The name sounds a little confusing but we can discuss that later). If a lot of effort is required for the existing GTK port to work with GTK 4, then I suggest maybe creating a new port.
I know that substantial work is required towards creating a new port and that there might not be enough resources to do even that. However, I am highly interested in making a new port for wxWidgets, so I'd like to discuss how we would get to work with this port. Another reason for discussion is so that I can avoid wasting time on something that might not get merged in the end.
Miscellaneous Motivational Paragraph Writing an entirely new port from scratch is not an easy task. I have never contributed to wxWidgets before nor have I worked with GTK at all. However, I believe I am capable of quickly learning both wxWidgets' internals and GTK 4. When I first started Saucedacity (now modern-day Tenacity), I knew not a single thing about Audacity's internals or wxWidgets, but I was able to quickly learn through the codebase and now have a better understanding of the codebase in general.—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
@generic-pers0n Whether it's better to create a new port or continue adding GTK 4-specific parts to the existing files isn't totally clear, but, in doubt, I'd rather keep the current approach as, after all, it worked relatively well for GTK 2 and 3, which also differ a lot.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Jonathan
Migrating from GTK 3 to GTK 4 is less painful than the migration from GTK 2 to GTK 3 was.
See the GTK migration guide at https://docs.gtk.org/gtk4/migrating-3to4.html, it covers what changes can be done in GTK 3 in preparation for GTK 4.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Last time I looked there were parts of wx API that simply could not be implemented in GTK 4 at all, so this is definitely not going to be very simple. But, again, any help is wholeheartedly welcome, including any incremental improvements.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
Migrating from GTK 3 to GTK 4 is less painful than the migration from GTK 2 to GTK 3 was
Hrm. For wxWidgets, I think not so much. Perusing that rather extensive list (it's been a while), it's one kick to the crotch after another.
"Stop using grabs"
oof...
"Adapt to GtkWindow API changes"
some of it is gone, and it's been renamed to GdkSurface, so probably
oof...
"Adapt to GtkContainer removal"
sigh...
"Adapt to GtkStyleContext API changes"
i.e. much of it is gone, as is GtkWidgetPath entirely, so wxRenderer and wxSystemSettings are wrecked, so that's another oof...
"The ::size-allocate signal has been removed"
oof...
"Adapt to drawing model changes. This area has seen the most radical changes in the transition from GTK 3 to GTK 4."
uh huh...
"GtkWidget event signals are removed"
oof...
"Stop using GtkWidget::draw"
oof...
"GtkMenu, GtkMenuBar and GtkMenuItem are gone"
oof...
"GtkToolbar has been removed"
oof...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Paul Kahler
phkahler left a comment (wxWidgets/wxWidgets#23415)For another software project, I made a checklist for the recommended changes that can be made while still using GTK3. Most of those are reasonable, but what angered me most was that I went all the trouble for "Stop using direct access to GdkEvent structs" by using accessor functions, and then for GTK4 a bunch of those functions changed name or were missing. Between that and the menu stuff changing and me not being adept at GTK of any version I gave up. It is still something I consider important, but the effort is non-trivial and impossible to do incrementally unless you can disable large portions of your app while porting one piece at a time. And we don't even use widgets....
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ginger Old
laoshaw left a comment (wxWidgets/wxWidgets#23415)gtk4 is now the default in new distro, hope wxWidgets can support it soon.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23415)Please don't leave comments about hoping that something happens. We all know that GTK 4 is the current GTK version, but this is not enough to somehow make wxWidgets work with it.
If you can work on it, please help making it happen.
If you can fund the work on it, we can discuss it too.
But just hoping doesn't help, unfortunately.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Avery King
generic-pers0n left a comment (wxWidgets/wxWidgets#23415)For another software project, I made a checklist for the recommended changes that can be made while still using GTK3. Most of those are reasonable, but what angered me most was that I went all the trouble for "Stop using direct access to GdkEvent structs" by using accessor functions, and then for GTK4 a bunch of those functions changed name or were missing. Between that and the menu stuff changing and me not being adept at GTK of any version I gave up. It is still something I consider important, but the effort is non-trivial and impossible to do incrementally unless you can disable large portions of your app while porting one piece at a time. And we don't even use widgets....
Before I say anything, I need to disclaim that I'm also not very adept at GTK, so I'm going to try my best to figure it out.
With that disclaimer out of the way, I think it's a good idea to start with refactoring the current GTK 3 implementation. Maybe from then we can experiment with a GTK 4 implementation once we're no longer using deprecated GTK 3 features. I'll see if I can experiment with modifying the current GTK 3 implementation to avoid usage of deprecated features.
Finally, I have a semi-relevant question: assuming we were to start a new port for whatever reason, what's anyone's thoughts on gtkmm? It looks like it'd be more appropriate to use considering wxWidgets is written in C++, but anyways...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#23415)Sorry, but I have serious doubts that laying 2 libraries abstracting GTK on top of each other is going to be useful, I suspect we'd spent time fighting with not just GTK but gtkmm too then. And it would be nice to avoid rewriting all wxGTK code, even if it seems like we'll have to rewrite quite a chunk of it anyhow :-(
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Avery King
generic-pers0n left a comment (wxWidgets/wxWidgets#23415)Sorry, but I have serious doubts that laying 2 libraries abstracting GTK on top of each other is going to be useful, I suspect we'd spent time fighting with not just GTK but gtkmm too then.
Yeah, no, you're definite right about that 😅
I think I had the thought in mind that we could continue with a rewritten GTK port using gtkmm instead of regular GTK.
And it would be nice to avoid rewriting all wxGTK code, even if it seems like we'll have to rewrite quite a chunk of it anyhow :-(
True, and at least my previous statement regarding gtkmm was mainly a thought. I still haven't made a deep dive into this entire task yet, but I'm looking into it further right now.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.