Upgrade to GTK4

[Jacalz]

The latest version of GTK (formerly GTK+) is version 4. It brings many changes and improvements. See https://blog.gtk.org/2020/12/16/gtk-4-0/ for more details (see https://blog.gtk.org/2021/03/30/gtk-4-2-0/ for GTK 4.2 and https://blog.gtk.org/2021/08/23/gtk-4-4/ for GTK 4.4).

While GTK+3 still is supported with bug and security fixes, it would be nice to upgrade to the latest version to take advantage of many improvements. The migration guide can be found here: https://docs.gtk.org/gtk4/migrating-3to4.html.

[Thanatomanic]

A simple question though: why?

[Jacalz]

Better hardware acceleration, improved OpenGL renderer and a lot of improvements to the library. There are a bunch of improvements and I think that’s reason enough unless porting takes a tremendous amount of effort. From what I’ve heard, the transition form 3 to 4 should be considerably smoother than from 2 to 3.

In the long run when all my other applications are GTK4 (with Gnome 43, most, if not all, of the core applications will be using GTK4), it would be nice to avoid the need to have both GTK+3 and GTK4 installed.

[Entropy512]

In addition to that, I'm sure at some point, GTK3 is going to go EOL.

Starting to wonder if the release after 5.9 is going to be mostly a restructure/rearchitecture for future maintainability release: Already in progress - exiv2 Should be done IMO, and ART can serve as a reference - libraw After my time digging through the language engine and translations, I really think that an attempt to move from the homegrown translations/localization engine to something like GNU Gettext will save a lot of pain in the long run - I might start taking a look into this after I get back from vacation And now - GTK3 to GTK4. We're probably at the point where any reasonably modern distribution will have GTK4 support. IMO doing this earlier would have been a bad idea, since GTK4 was, for example, released after Ubuntu 20.04 - but at this point pretty much all major distributions have done another LTS release that should include GTK4. (Although, at least for Ubuntu, we're not quite to the point where Canonical has flipped the switch for upgrading LTS releases directly, apparently that has to wait until the first point release which I think is scheduled for right around now... For example any of my machines at work are still on 20.04, IT hasn't signed off on deploying 22.04 even for initial testing yet.)

[Christian-Kr]

Hello to everyone,

is anyone currently working on that? If not, I would just give it a try.

Greetings

[Lawrence37]

@Christian-Kr If you want to I can assign this issue to you.

[Christian-Kr]

Hello Lawrence,

I just want to get an overview first, and prepare some things.

From a different issue threat I saw this: https://github.com/Beep6581/RawTherapee/issues/6103. Something like that is good know, cause such a task would be part of the preparation. :-)

Greetings

[Benitoite]

GTK+4 has a rewritten GDK backend for macOS that allows OpenGL rendering. GTK+3 macOS backend is strictly Cairo-based. This could be an improvement for macOS.

[Christian-Kr]

Edit: My thoughts are written down with a migration from gtk3 to gtk4.10 in mind and also remove or replace things that where deprecated with gtk4.10.

Hello to everyone,

just my few cents on this porting task. First of all: I am not a gtk developer. Most applications I've written use qt. I just don't matter about what framework/toolkit will be used, it might just be important to give the information here.

I had a look into the porting task to gtk4 for some time now. What I have seen so far is: This task is huge! It might be possible, but it is so huge that the project should think about whether its worth it. From my point of view it would take nearly the same amount of time writing everything (gui related) new in gtk4 or qt. It is not only the amount of changes from gtk3 to gtk4, but also that changing so much in an existing code base (which is not always good documented) needs a lot of caution and testing, cause the behavior might change unexpectedly.

On the other side, writing the gui part new is also a lot of work. But it might also be a chance to refresh and restyle the gui code base. Maybe switch some architectural designs.

Please don't understand me the wrong way, I don't want to demotivate. But I think a port of the existing code is not the best option that is available here.

In the end, no matter which option will be selected, it is a lot of work :-D.

Greetings

[Lawrence37]

It would be nice to refractor the UI code, but I'm not convinced the GTK4 port is comparable to a complete rewrite. The migration guide lists everything that is required to transition from GTK3 and at first glance it looks like only some of the RawTherapee code is affected. Can you give an example or two of why upgrading to GTK4 is a huge task?

[Christian-Kr]

Hello Lawrence37,

thanks for your reply.

I also thought that it couldn't be such a big task with the migration guide in mind. But after just starting with the migration and finding all the related code parts, I changed my opinion slowly over time.

From my point of view there are several things:

• The switch to Gtk Paintables and Gtk Textures seem to a effect a lot of stuff from self implemented RTImage and the use of RTImage.
• A lot of custom widgets with preferred_*_vfunc has to be rewritten to measure_vfunc.
• The removal of EventBox and Container seem to me like a bigger change, cause one has to think about which functionality a container had and how to replace it now. The EventBox are not needed anymore, but taking a look at the code I was not always sure an EventBox widget has not been used for other stuff too.
• It also looks like a bigger change, that code needs to be written async for dialogs. Especially message boxes where used all over the code with the run method, which should now be implemented with signals.
• The last one might be, that there is no gtk lock anymore when calling gtk functions in other threads. I am not an expert of threads for sure, but there are gtk lock parts where someone has to think more carefully about, how to implement ui parts and prevent a call to gtk from within threads.

Maybe it is just my missing experience with gtk, that lead me to the conclusion. But so many code parts need a full review and the code is from time to time not that good documented, that I think a rewrite (same layout and presentation of gui - just another new code base) is not so much work in comparison to a migration.

P.S.: I started with the port and for now have a ported rth-cli version. That was also a little bit of work to, cause I switched to newer glib gio and so on...

Greetings

[Lawrence37]

Those sound like specific things that affect small parts of the GUI code. I understand the amount of work is high in absolute terms, but keep in mind there is a lot of GUI code especially for all the tools (just look at how many widgets are in the local adjustments tab). Given your experience so far with the port, what is your estimate of how much work is required compared to a complete rewrite (10%, 25%, 50%, etc.)?

[Pandagrapher]

I agree with @Lawrence37: it shouldn't be a complete rewrite. But to simplify the port to Gtk4, we will need to firstly improve some part of the GUI (still with Gtk3) to adopt native Gtk mechanism instead of custom one. This way only custom widgets will need a lot of migration work to Gtk4. For instance, that's what I have done improving the RTImage class: it now relies more on Gtk mechanisms (but couldn't fully use native Gtk class due to Windows limitations... :( ).

[Christian-Kr]

Ok, got it. Maybe it is just, that I doesn't have enough experience with GTK. Or, I just cannot distinguish the right way between "must have for a migration" and "this should be restructured for any reason but not a must have for a migration". So I think I am more or less out and won't jump into migration any further.

I hope someone finds the time to do the migration in future, cause I really like what you all have created. :-)

Greetings

[mutchiko]

So let us say that, hypothetically, the amount of effort needed to port RawTherapee to GTK 4 is equal to what you need to port it to something different (say Qt 6.x for example), would you take the GTK version or the Qt one?

This is just a simple question, i totally know how hard it can (or it will) get for any of the above options to be in a usable shape, but i need to know if people prefer something other than GTK in general, that's all.

[Lawrence37]

I don't know much about Qt, so I can only share some pros and cons of GTK from my experience and weigh them against someone else's analysis of Qt.

Pros

• Developers here are at least somewhat familiar with GTK from first-hand experience
• Other GNOME libraries are used throughout RawTherapee and GTK leverages and integrates with those libraries
• Great C++ wrapper and ability to easily drop down to the native C API

Cons

• Maybe not as well maintained for Windows (and macOS?)
• Specific issues or bugs like slow reparenting

Also, if there were to be a rewrite, other GUI toolkits are available.

[Pandagrapher]

IMHO, here a list of RT GUI parts that should be rewritten/simplified/improved before migrating to Gtk4: @Thanatomanic @Lawrence37 As you also worked a lot on GUI, do not hesitate to update the list :)

• Custom RT widgets: -- File browser: Currently, File browser is coded as a global custom widget (an unique Gtk::DrawingArea). I guess this is due to GDI handler number limitation on Windows that can be reached easily if one Gtk::DrawingArea was used by thumbnail. Maybe also performance issue. With Gtk4, it is maybe now more interessesting to use native Gtk widgets at maximum and to keep custom widget for thumbnails only. That would simplify a lot of GUI code. -- Image area / Edit widgets: Edit widget mechanism works perfectly when used by small group of Edit widgets (ex: spots). They are complicated to managed when used in a huge number (ex: rectangles or ellipses in Locallab). They are also part of the Image area that imply to redraw it when the user interacts with an Edit widget without impact on the image. Maybe we should try to improve this part of GUI (using Gtk::overlay to manage the Edit widgets independently of the Image area ?). -- Curves: This custom widget can be optimized using common native Gtk widget (ex: for buttons) and only one custom widget (Gtk::DrawingArea) to draw the curves according to the selected one. -- RTImage: See if GDI handler limitation is fixed with Gtk4 then completely drop the last part of custom code (after Pull Request #6830) to fully use native Gtk mecanism.
• Others: -- RT windows: They are not handled correctly between each other (ex: Main window is frozen when Preference window is opened. However, Preference window does not stay on top). -- Keyboard shortcuts: Shortcuts managements can be complicated with a lot of possible regressions if focus is not perfect between widgets. I believe Gtk4 has improved the shortcuts mecanism. Maybe we can anticipate the migration improving the code before (as other Gtk app as Gimp or Inkscape did). -- Localization: I do not think it is mandatory for the Gtk4 migration but maybe we can migrate to library as gettext (as Gtk internaly use). That will allow to use some collaborative website for translation.

[Benitoite]

From a mac performance perspective, gtk3 has been disappointing. (problems mousing menus, keyboard shortcuts not passing) Qt seems more supported on mac than gtk ever was. I have no experience with gtk4 on mac. Qt6 would be the minimum for macOS on Apple Silicon, as it is actively supported and the Qt5 port for mac arm64 is incomplete.

[Jacalz]

The problem with QT is that they have a weird commercial licensing situation in that their code for LTS releases is behind a paywall for something like a year. Doesn't quite sit right with me from an open source perspective.

[Lawrence37]

A month or two ago, I tried investigating the GDI handle issue. To my surprise, each editor uses much fewer handles than before, "only" two hundred something. That's low enough for dozens of editor tabs. I don't know if it is due to something we changed or if GTK3 became more efficient recently.

To the list of possible improvements before moving to GTK4, I'll add having all widget style properties in CSS instead of in the code. There's a handful of places we set padding in the code for example. It's better to have all style and theme properties in the CSS files.

@Hombre57 has also done a lot of work on the GUI.

[mutchiko]

Personally i see 2 options:

1. GTK 4: most viable option, from my experience, it runs smooth on windows, linux and mac, and since RT depends on some GNOME libraries, it just makes sense to use it when you have already spent some time with GTK .
2. QT 6.x: i consider it the fall back option, if -for some reason- GTK 4 has a big problem that prevents RT from climbing the ladder of successful UI experience (which i highly doubt).

And i see people complaining about GTK 3 all the time, isn't it the reason why people use MATE to this day? i don't want to push it off the table yet,first i want to see how GIMP 3 is going to be, who knows? it might change our opinion about GTK 3 to the better.

@Jacalz as for your concerns about Qt 6 licensing, 6.5 (LTS) has a LGPL license, you can read about that here.

It would be great if we could put two simple mock-ups for RT next to each other, one made with GTK 4 and the other made with Qt 6. if the opinions become very different you can publish photos of them after the 5.10 update, and get some feedback and maybe draw in some Qt expertise? it is just simple way to avoid putting any efforts waste.

[Benitoite]

I know a lot of time and effort went into coming up with the themes for gtk; probably as much attention to detail would have to be payed in a qt port, no idea if that would be easier or harder than gtk. Licences for qtbase: https://github.com/qt/qtbase/tree/dev/LICENSES