WIP Gtk4 transition

[dterrahe]

Showing this now to demonstrate progress and to clarify the massive amount of work remaining. Offers of help would be very much appreciated.

This started out as a conversion of the widget event handling to the eventcontrollers that gtk4 introduced but that have been backported to gtk3 to ease the transition. I then added the h/vbox conversion that has been merged into master. Then a list was added, in darktable.h of all the functions and types that no longer exist in gtk4. This allowed a first compile against actual gtk4, but of course running only gave errors and failures. Then some of these dummy definitions were turned into actual equivalents, in some cases by adding an intermediate layer. Our custom types, bauhaus and dtgtk..., were either (partially) converted or extended with the legacy GtkWidget signals and a translation callback.

This now allows starting a, severally broken, session. The lighttable (thumbtable) does not work at all (will probably need to be reuild), so if you want to play around (in a pristine confdir! Obviously don't use this in your production environment. I hope I didn't need to say this) you want to give a single image name on the command line, so you immediately switch to the darkroom.

Again, everything is broken! No dialogs/popups/menus/dropdowns (you can scroll through bauhaus combo options though). Broken css. No shortcuts. Layout problems everywhere. Module Groups don't work, so all modules are always shown. You'll have crashes and your console will be flooded with signals that no longer work and will need to be redirected. This gives an indication of the amount of work remaining, which is most. Consider this just a start on the low hanging fruit.

BUT what this does mean is that there is a working base from which to continue the porting effort. Which is much more than I was hoping for so soon. It means any approaches can immediately be field tested and changed without too much work wasted if they don't work. A lot of that still means basic infrastructure work, replacing stuff that we depend on everywhere and that has been kicked out of gtk4 completely. My intention is to run this as a parallel fork for a long while (count >year if I stay motivated at all) so that means I'm trying to keep the areas touched as limited as possible. Any fixed that can be applied to master I'll backport so as to minimise the divergence. Then when all the building blocks are in place, we'll need to start applying fixes all over the place. Removing inefficient translation layers that are temporarily put in place in this first phase. These might by then be simple search&replaces, but they will touch everything so by then master needs to be frozen (or this port hard forked) because rebasing will no longer be feasible.

Until then, I would like to request that there's a (very) soft freeze on the central infrastructure (all the dtgtk types, bauhaus, lib/module central infrastructure; basically the files touched in this WIP plus some). No uncoordinated cleanups/style fixes/constifications that would make rebasing a pain. Until more volunteers step up, one would not want to drain my motivation too quickly. Since css/styles have been changed a lot so will need to be fixed anyway, this might offer an opportunity to rebuild using some of the ideas in https://discuss.pixls.us/t/i-am-working-on-a-rebrand-for-darktable/44382 if they are feasible.

Anyway, after all that, a teaser screenshot:

[dterrahe]

CI obviously fails, because you need gtk4 libs installed to compile/run.

[zisoft]

I am really interested to jump in here.
How can we coordinate things to avoid overlapping work?

Any recommendations on where to start?

And what about #15920 ?

[dterrahe]

How can we coordinate things to avoid overlapping work?

So, practically, as I described I see this going in two phases; one a sort-of preparation phase where I keep building this PR, which is a sort of compatibility layer, really. It touches the core infrastructure (bauhaus, the dtgtk classes, gtk.c helpers etc) but doesn't require (by intent) touching the wider codebase, so the area where we clash with further development in master is "limited" (no unmanageable rebases). If you want to contribute here, you can submit PRs to my branch directly. Don't do big chunks and let me know when you start experimenting with something, so we don't waste double effort. At the same time the main codebase can be prepared for the transition by moving to newer gtk4-methods where they have been backported or already exist in gtk3. Or where gtk3 specific constructs are used, it may be possible to refactor them heavily so that all the porting eventually only needs to be done in one central place. This was the purpose of #19354 and previous similar. Those are not complete yet, so you can continue there, if you want? Myself I'm for now not spending too much time on thumbtable and modulegroups as I think those may benefit from deeper restructuring anyway (the way gtk4 prefers to subclass/assemble widgets is different from gtk3) so spending too much time on migrating current code when later replacing it all would be inefficient. Again, I'd appreciate it if you submit stuff in early stages (as draft PRs) so I can review and either give advice or discuss direction.

Phase two, the "hard fork" or "master switch" is still quite a way off. Let's not waste too much time speculating about what that will look like exactly. It definitely should involve a cleanup where compatibility layers are removed. For example, my current code just replaces EventBoxes (which disappeared as they are no longer useful) with Boxes, to keep the existing code working. But really they obviously should be completely removed eventually. Mucho stuff like that. Maybe even still left over from the gtk2>3 migration for all I know.

Any recommendations on where to start?

Which particular areas you want to work on is up to you really. I know gtk3 in the context of how we (ab)use it in dt. I'm starting to know gtk4, but only the parts where I've delved into the actual migration issues. I haven't done this on other projects before, so I don't really know what I'm going to come across or what will be the really hardest issues to solve. As said, I'm seeing it as an opportunity for cleanup/simplification/redesign as well and then may include long-asked-for user visible (styling etc) updates. But only where it is feasible and there's input from others. I can't let the stuff I'm carrying myself get too unwieldy or it will go nowhere. This should not be a mozilla restart.

Where can you get ideas?

• https://docs.gtk.org/gtk4/migrating-3to4.html
• https://github.com/dterrahe/darktable/blob/237844e7274437cc40a5235a0ceef2d13211dc68/src/common/darktable.h#L1301-L1536 These have all been disabled because they disappeared or changed
• The errors you see flying by when starting the ported version. And the stuff that isn't working/looks wonky.

Maybe you'd be interested in exploring the whole gtk_menu_item situation? Is this something that can already be implemented in gtk3? Could you propose a refactor&simplification that would centralise eventual changes?

And what about #15920 ?

What about it? Doesn't seem to be progressing much/at all. I don't know what their intentions are if any, beyond a project plan that contains little useful/correct information. In OSS code talks, I'm afraid.

[zisoft]

I cloned your repository to make the first steps on branch gtk4_compile.
Compiling on macOS fails because GDK_WINDOWING_QUARTZ is no longer defined in gtk4.
We have 89 occurrences in the codebase...

Anyway, its just the beginning... let's move on

[zisoft]

I finally got it to compile and run on macOS, so I have a base to continue:

I will submit a PR to your gtk4_compile branch