GTK4 migration

[caclark]

I intend to use the master branch as the development branch for GTK4 migration. Using a GTK4-specific branch does not make sense to me.

The immediate problems are the problems with meson.build and dependencies. That will be fixed pretty quick, I hope.

The longer term problem is that the master branch will not give a clean compile. The sources are just too wrong for GTK4 compliance. That will take longer to fix.

In the meantime I do not see a problem in committing pull requests that do not pass the auto-run validation checks.

A while ago I got Geeqie to compile under GTK4 by commenting out all compile errors - a total of 5414 lines were commented out (and it did not run - just took one step and fell over)

Maybe I can merge that in, but I feel the code will just end up convoluted again.

My intention is just to keep hacking at the code (maybe with some commented-out sections) until it compiles.

Suggestions and criticisms are all good....

[caclark]

For those who are interested in the trivial details of progress with this, I made the first GTK4 migration commit in September 2022.
At the time I thought that the migration would be difficult - and I was really, really, wrong. It is far worse.

In spite of cutting out a lot of dnd and menus, there are still 738 compile errors left.

But I will keep at it. Beer consumption is up...

[gusnan]

Keep up the great work!

[xsdg]

@caclark What can we do to help without stepping on your toes?

[caclark]

@xsdg Thanks

Compile errors have gone from 738 to 340. @qarkai has knocked some of them out but most are from simply pointing Codex or GptChat to a random problem.

I will continue for another day or so. Any problems that AI cannot solve I will let you know :-)

[qarkai]

In the meantime I do not see a problem in committing pull requests that do not pass the auto-run validation checks.

Maybe disable PR checks until there are no build errors in master.

[caclark]

It compiles and runs - but it is not usable.

Significant work remains to be done.

[qarkai]

Note: gspell dependency uses GTK3, and is not going to be ported to GTK4.
Geeqie complains about mixing GTK3 and GTK4 symbols when compiled with gspell
GTK 2/3 symbols detected. Using GTK 2/3 and GTK 4 in the same process is not supported.
Looks like new spellchecking library is https://gnome.pages.gitlab.gnome.org/libspelling/libspelling-1/

[barracuda156]

If possible, it is desirable to support both versions of GTK (which is done by a lot of apps, in fact even GTK-2, for w/e reason, is still supported often). GTK-4 has some regressions as compared to GTK-3, and those are “by design” (upstream thinks, for example, that broken GL rendering on a lot of hardware is perfectly okay as long as it is not the hardware they use…), there is also an unfortunate push of rust within GTK-4 ecosystem (avoidable at this moment, but who knows). It is certainly desirable to support GTK-4 along with GTK-3, but replacing is ambiguous in terms of user benefits.

[xsdg]

Hi. We've already decided to transition the Geeqie codebase from (functionally) GTK3-only to GTK4-only. You can see this mailing list thread for some of the motivation and decisions: https://www.freelists.org/post/geeqie/GTK4-fork

Supporting GTK4 along with prior GTK versions is not feasible for us.

[barracuda156]

I see, thanks for the info. This is kinda unfortunate, though for an image viewer specifically it should be fine (at least as of now, what got totally broken are video players, due to broken GL, but for images cairo rendering works fine).

[caclark]

@gusnan et al

There will come the point that Geeqie is runnable and usable, but not correct in details - there have been too many changes. How to get passed this stage without users using it and logging errors?

Just issue v3.0 and wait for the complaints? Followed rapidly by v3.0.1 etc.?

Does v<n>.0 have a special significance?

[gusnan]

For me (or Debian) the packages versions numbers matter very little, you (and other people here) probably have more to say about that.

In Debian, what we focus on (or should at least) is the next release version of Debian, and packages come into unstable (which is as it sound, the development area, and the packages there trickle down to the testing section when they have no release-critical bugs (according to Debian) reported on them. Testing is supposed to be the next version of Debian, and should (in theory) always be ready to be released. If a package isn't ready to be in the next release of Debian, it shouldn't be in neither testing or unstable.

There is however, another section "experimental", which has no automatic migration of the packages to testing, which is (as the name suggests) good for packages that might need more testing, or isn't ready for a Debian release yet.

For me it seems experimental could be a good fit for geeqie 3.* while in the GTK4 migration state, which means that while it's there, that version won't get to the next Debian. However, 2.9 is already in unstable, so it will migrate to testing (and will be a part of Debian 14 when it gets released). - It hasn't migrated to testing because of some dependency, but I'm certain that will be sorted. The package in unstable/testing doesn't get affected by an upload to experimental, they are separate.

[qarkai]

Experimental versions (alpha, beta) are usually released with numbers like 2.90 or 2.99. E.g. see KDE unstable.

[xsdg]

Just a little status update here.

First off, I added a GTK4 bug tag, so we can start tracking GTK4-specific bugs separately from other Geeqie bugs.

Secondly, I added a utility to make it easier for anyone using X11 to see the current status of git Geeqie without needing to setup a special dev environment. These will run completely independently of each other, and independently of any other Geeqie instance on the machine. Note that this uses Xephyr (a nested X server that runs under X):

# basic
$ ./tools/isolated_xserver.py -- "${PWD}/build/src/geeqie"

# Geeqie runs better with a window manager though
$ ./tools/isolated_xserver.py --wm xfwm4 -- "${PWD}/build/src/geeqie"

# And it'd be nice to have something to look at
$ ./tools/isolated_xserver.py --wm xfwm4 --link_path imgs=/path/to/some/images/ -- "${PWD}/build/src/geeqie" --file=imgs/

# And maybe a bigger Xephyr window, and what if we want to run geeqie under gdb?
$ ./tools/isolated_xserver.py --wm xfwm4 --link_path imgs=/path/to/some/images/ --xarg -screen=1920x1080 -- gdb "${PWD}/build/src/geeqie"
[…]
(gdb) r --file=imgs/
Starting program: /…/gitqi/build/src/geeqie --file=imgs/
[…]

I could imagine adding Wayland support if that would be helpful (weston and XWayland seem relevant on first glance)

[przepompownia]

@caclark Does reporting crashes make sense at this stage (f.e. as todo checkpoints)? The existing GTK4 issues (by @xsdg) contain hints too so they are rather special cases. I don't want to report things that are known to need to be done in a certain order.

[caclark]

@przepompownia

It seems to me that if in normal use it causes a crash, that is a loggable bug. (I am not expecting the current master branch to crash. I can make it crash but I am working on fixing that).
If it causes a crash in a once-in-a-blue moon situation, that would be a FIXME
Something trivial, or an improvement, (anything that I would probably ignore....) would be a TODO