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)

Reviewers

• Michael Strauß (@mstr2 - Reviewer)
• Lukasz Kostyra (@lukostyra - Reviewer)

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]

@fthevenet This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: mstrauss, lkostyra

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 70 new commits pushed to the master branch:

• 7b84551: 8377153: JavaFX FlowPane layout causing improper wrapping of TextFlow nodes with max-width styling
• 3948194: 8377930: Additional WebKit 623.1 fixes from WebKitGTK 2.50.5
• 6c2b48f: 8377904: Replace Double.parseDouble() with CssNumberParser
• ... and 67 more: https://git.openjdk.org/jfx/compare/3561d522ad1e40ac330a07958ad00eda3a24aa62...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@mstr2, @lukostyra) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[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.

[bridgekeeper]

@fthevenet This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a /touch or /keepalive command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[fthevenet]

/touch

[openjdk]

@fthevenet The pull request is being re-evaluated and the inactivity timeout has been reset.

[fthevenet]

From the comments on that PR and discussions on the mailing, I feel that there is a consensus that this change is a desirable thing to have in JavaFx.
I would very much like to get it reviewed, so that it gets wider exposition and testing as part of ea builds well in advanced of 27.
Thanks!

[mstr2]

Looks good.

[fthevenet]

Thanks for the review @mstr2

Could I please get a second review for this? @johanvos, @lukostyra maybe?
Thanks!

[lukostyra]

LGTM, verified on Ubuntu 24.04 with KDE.

[fthevenet]

Thanks for the review @lukostyra

[fthevenet]

/integrate

[openjdk]

@fthevenet
Your change (at version 555a66c) is now ready to be sponsored by a Committer.

[mstr2]

/sponsor

[openjdk]

Going to push as commit 8c8e59b.
Since your change was applied there have been 70 commits pushed to the master branch:

• 7b84551: 8377153: JavaFX FlowPane layout causing improper wrapping of TextFlow nodes with max-width styling
• 3948194: 8377930: Additional WebKit 623.1 fixes from WebKitGTK 2.50.5
• 6c2b48f: 8377904: Replace Double.parseDouble() with CssNumberParser
• ... and 67 more: https://git.openjdk.org/jfx/compare/3561d522ad1e40ac330a07958ad00eda3a24aa62...master

Your commit was automatically rebased without conflicts.

[openjdk]

@mstr2 @fthevenet Pushed as commit 8c8e59b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.