[GTK4] Migrate deprecated FontChooser to FontDialog

[ptziegler]

This moves all native FontChooser bindings from the shared GTK to the GTK3 component and also defines new GTK4 bindings for the FontDialog API.

Note: The FontDialog doesn't seem to remember the initial font that is passed as an argument. This looks like a bug within GTK, given that the same behavior also happens for the FontDialogButton[1].

[1] - https://gitlab.gnome.org/GNOME/gtk/-/issues/6892

[ptziegler]

In terms of appearance, both dialogs are pretty much identical, though I think the old one looks better...

GTK3:

GTK4:

Note that this PR currently depends on #1582 because I'm using the new AsyncReadyCallback class.

[github-actions]

Test Results

   383 files   -   100     383 suites   - 100   5m 12s ⏱️ - 2m 34s
 4 095 tests ±    0   4 088 ✅ +    3   7 💤 ±0  0 ❌  - 3 
12 147 runs   - 4 026  12 064 ✅  - 4 016  83 💤  - 7  0 ❌  - 3 

Results for commit 0ab423e. ± Comparison against base commit 7300cb4.

♻️ This comment has been updated with latest results.

[akurtakov]

This PR should be kept strictly to FontChooser->FontDialog change and the async helper code change together with adopting existing code should go into #1582

[ptziegler]

This PR should be kept strictly to FontChooser->FontDialog change and the async helper code change together with adopting existing code should go into #1582

Of course, that's why this is still marked as "draft" :)

The plan was to wait for the other refactoring to be merged, do a rebase and then the offending commit should disappear on its own. I just didn't want to use the "old" approach when refactoring it anyway.

[laeubi]

@ptziegler we have now GTK4 build enabled, so if you rebase your PR it will at last check that compilation has no issues!

[akurtakov]

Please continue with this one.
Note that starting with https://download.eclipse.org/eclipse/downloads/drops4/I20241127-1240/ builds for gtk4 are provided and can be started passing SWT_GTK4=1 env variable.

[ptziegler]

As described in the linked issue: What exactly is the procedure for dealing with actual bugs in GTK? As far as I can tell, there is no way to work around this problem inside of SWT.

[akurtakov]

One option is to stay with FontChooser until it's fixed and use FontDialog in an "if (GTK4 > 4.16)" or similar version block where we know it works.

[ptziegler]

I've tried out the FontChooser with GTK4 and there I see the same issue...
Given that the FontChooser dialog looks exactly like the FontDialog dialog, I believe that internally, the method calls are simply delegated from one to the other. So I don't think there is anything to gain by keeping the old implementation.

[ptziegler]

I don't see any warnings/errors regarding the gtk_font_dialog methods, so I believe the building the binaries fails due to -Werror.

2024-12-08T07:47:12.4387322Z [INFO] [exec] -e *** GTK4 Build failed, aborting further actions..
2024-12-08T07:47:12.4394328Z [INFO] [exec] cc1: all warnings being treated as errors
2024-12-08T07:47:12.4399139Z [INFO] [exec] make: *** [make_linux.mak:144: os.o] Error 1

But why doesn't this also happen on the master?

[laeubi]

The Jenkins build succeeded but windows was aborted/timed out

For the Github verification, this might be because ubuntu is using a more recent GTK version (with more deprecation) as our Jenkins job. So this can be ignored for now until we reaching a clean state, that's also the reason we currently not build for other architectures than x86.