On 11/19/24 5:17 PM, J Leslie Turriff via openSUSE Users wrote:
The learning that xdg-desktop-portal does not work for all cases on all DEs came later. The solution I'm currently thinking about is to set it to two only when running in Plasma but Firefox does not have that possibility and it requires to bring back some KDE detection mechanism in Firefox and set the pref only in that case. This is the plan but given a bit of limited time it will take a few more days to create a patch.-- In addition to Plasma, KDE3 and Trinity Desktop (a fork of KDE3) are still available and actively used.
The problem was created upstream in whatever electron or xdg-desktop-portal did. The problem is a lack of validation of what utility they find in the Linux $PATH and attempt to use as a fileChooser. If they find 'kdialog' - they blindly assume it is Plasma's kdialog which supports the --attach option to bind the dialog as a modal dialog to the parents window_id. Problem is that kdialog from TDE/KDE3 does not support the --attach option and fails with an error. However, this is never checked in the electron implementation so the default Gtk dialog is not provided if kdialog fails. This leaves the application without any file-dialogs. This has bitten Mozilla and Microsoft vscode and the vscodium port. (and others I'm sure, but those are what broke on me) The electron commit responsible for the vscode/vscodium (and likely others) issue is: https://github.com/electron/electron/pull/42045 This must be an upstream fix. It cannot be that electron and/or xdg-desktop-portal breaks things for numerous apps and desktops -- but then leaves the problem it create to every app and desktop to work-around, patch and fix. That's just nuts. It's also a bit of a depressing glimpse at how software is being put together today by grabbing bits and pieces from around the internet and then "integrating" features into larger more mature packages without fully understanding the limitations of the library or utility used, or doing thorough validation on what utility was actually found and further whether it worked the way it was envisioned to work by the integrator. The laughable part of how this is done is the PATH ordering can make or break the file-chooser if you have multiple versions of a chooser utility installed by various desktops. If the older version's path is listed before the new, then your dialogs fail just be the luck of how the search-directories in your PATH or ordered. So upstream needs to fix this as it make no sense for every app that uses whatever code that is to have to reinvent differing fixes for what was broken upstream. Worst case, all app with have to patch and fix whatever chooser like kdialog that is being used. The TDE/KDE3 discussion is at https://mirror.git.trinitydesktop.org/gitea/TDE/tdelibs/issues/318 Mozilla at least provides an about:config setting that lets you turn the portal implementation off (or just switch it back to auto) and the Mozilla apps do fine then. The downside is the user wonder what the hell happened to being about to open, print or save a file in the mean time. It took by chance working with a skilled vscode dev to get the magic command line arguments to even see what was happening. A general Linux user, not used to crawling through issues and pull-requests on GitHub, etc.. would just be screwed. That's just the kdialog part, there are other similar utilities that a sought and found that are in the same boat given the comments of no file-choosers since June for vscode. That's about the size of it. Helping push the upstream folk to just make sure the dialog it choose actually opened (a simple 1 sec timer test after the chooser was launched should provide a valid check of whether or not a chooser displayed, and if not, or in case it returned an error, just provide a sane fallback to the default Gtk chooser solves all problems. SUSE raising/pushing the issue may speed the wheels of progress to get a fix much faster the users requesting it (hint, hint....) The vscode/vscodium workaround of just removing part of your PATH that finds the old kdilog or zenity, etc... and provide the rest of the path as a local PATH for launching vscode. Works just fine, the old default Gtk dialog pop right up and that app works again. Maybe all this new stuff isn't really being programmed at all. Maybe it's just a couple of junior programmers having a chat with ChatGPT anymore. That would certainly explain this half-bake implementation to find an use native dialogs. I guess ChatGPt just left out the part about kdialog being a gui-tool designed for shell-progrmmer use -- but it can generate choosers too. Mind boggling. -- David C. Rankin, J.D.,P.E.