8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration

[fthevenet]

Flatpak is a framework for distributing desktop applications across various Linux distributions, that runs each application into its own sandbox to limit its access to the host environment to the strict minimum, including access to the network, HW devices or the host file system.
To do so, it provides a specific set of APIs, known as "XDG Desktop Portal " that the guest application must be aware of to take full advantage of ; which is not the case for Java/JavaFX based applications.

Fortunately, some level of support for XDG Desktop Portal is baked into GTK3, which JavaFX could easily take advantage of.
One such opportunity is replace explicit uses of GtkFileChooserDialog with GtkFileChooserNative.

GtkFileChooserNative is an abstraction of a dialog box suitable for use with "File/Open" or "File/Save as" commands. By default, this just uses a GtkFileChooserDialog to implement the actual dialog. However, on certain platforms, such as Windows and macOS, the native platform file chooser is used instead.
When the application is running in a sandboxed environment without direct filesystem access (such as Flatpak), GtkFileChooserNative may call the proper APIs (portals) to let the user choose a file and make it available to the application.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed (2 reviews required, with at least 1 Reviewer, 1 Author)

Issue

• JDK-8374630: Replace GtkFileChooserDialog with GtkFileChooserNative to allow for better Flatpak integration (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jfx.git pull/2025/head:pull/2025
$ git checkout pull/2025

Update a local copy of the PR:
$ git checkout pull/2025
$ git pull https://git.openjdk.org/jfx.git pull/2025/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2025

View PR using the GUI difftool:
$ git pr show -t 2025

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/2025.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back fthevenet! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[mlbridge]

Webrevs

• 00: Full (555a66cf)

[lukostyra]

It's a small change but we'll have to thoroughly test it before integrating. I'll take a look at it, but a second pair of eyes will be needed for verification on Linux.

/reviewers 2

[openjdk]

@lukostyra
The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 2 (with at least 1 Reviewer, 1 Author).

[kevinrushforth]

@azvegint Can you take a look at this?

[fthevenet]

Thanks for looking into this, @lukostyra

Here's a thing that I noticed during my own testing that might be of interest: I have verified that when running a test app as a standard process, the file chooser dialog resulting from calling GtkFileChooserNative is a standard GTK dialog that is identical to the one produced via GtkFileChooserDialog (and when running the test through the XDG portal API, the dialog is indeed a "native" dialog that differs depending on when display environment, which is the whole point for this change).

There is, however, a visible difference in what is produced by this implementation compared to the previous one in JavaFX: the "Open/Save" and "Cancel" buttons do not show an icon besides the label:

The reason for that is that GtkFileChooserNative does not appear to support using GTK_STOCK_OPEN/CANCEL that defines both the default (and localized) label and icon for these actions: instead it displays the raw string if passed, e.g. "gtk-cancel". It is perhaps unsurprising since GTK_STOCK_OPEN et al have been deprecated since v3.10[1], while GtkNativeDialog was introduced in 3.20.

I looked, but couldn't find an alternative way to add the icon in the new implementation (not that I personally think it is a big loss, but ideally this change shouldn't introduce any visual differences when used in the same context).

I have, however, verified that passing NULL as the buttons' label to use the default does result in properly localized labels when switching languages (a far more important point, IMO).

[1] https://docs.gtk.org/gtk3/const.STOCK_OPEN.html

[johanvos]

This works as expected. I will have a deeper look though, as there might be edge cases that I'm missing. Also, the comment above related to label/icon needs more investigation.

[johanvos]

I had a deeper look. All code changes look fine, and I believe it is the right thing to do (including the support for flatpak)
We have some technical debt when using GTK, and using deprecated constants like STOCK_OPEN add to this debt. On my Ubuntu 22.04, the icons are not even shown with the existing implementation, so there is no difference for me, as far as I see.
@fthevenet what OS/GTK version is used for the screenshot that you pasted and that does have the icons?

I'm pretty neutral on design in general, but it seems that removing the option to show an icon next to the label is aligning us more with industry standards. Since this is about an OS/Gnome component, I believe there is no problem if this results (on some systems) in a changed UI -- other apps will probably show similar evolution.

[fthevenet]

Thanks @johanvos

I took those screenshot on Fedora 43 (with KDE 6.5.4). The version of the bundled GTK3 libs is 3.24.51.

Another issue I've noticed with these icons is that if I run a light color theme on my env, the icons are still there but almost invisible, as they are drawn in white on a very light grey background:

If you click the button so its background color changes, you can see the icon it still there:

Maybe this is what's happening on your machine, @johanvos ? At any rate, for all the reasons you mentioned, I believe it's not really worth investigating this particular problem further and that simply getting rid of the icons is the best way forward.

[fthevenet]

Any chances that this will make it to JavaFX 26, since we've now entered RDP1?
If not GA, what's the process to get it into the first 26 update?
I'm familiar with the JDK backport process; does JavaFX uses a similar process?
Thanks

[kevinrushforth]

This enhancement request seems better suited for JavaFX 27.

We do use the same process as the JDK does for backporting. See this message. Enhancement requests need approval to be backported to JavaFX 26 during rampdown. You can make the request, but I don't think it is a good candidate for getting in late in the release cycle.

[fthevenet]

Thanks for your reply.
There's one thing that remains unclear to me after going through the linked message: does the same process apply after 26 ga is released? I.e. will the bar for this enhancement still be as high if targeted at 26.0.2, provided that by then it will have "baked" into the mainline for about 5 months? Or does JavaFX not allow enhancements to be released in updates as a policy anyway?
Thanks.