nativefiledialog
nativefiledialog copied to clipboard
mlabbe
KDE support
Hi, I'd like to integrate your library in my project but it does not seem to support KDE. It instead uses the Gnome file picker which is a very suboptimal experience with a KDE setup. Beyond the different interface, it does not integrate with favorite locations or lacks many navigation controls.
Would it be possible to add KDE support?
I just filed issue #42, which is potentially a solution that could solve this problem. Experiment #42 provides a runtime check to see if GTK/GLIB is available and then dlopens the libraries if available to use them.
In principle, somebody could implement a Qt or KDE backend using the same technique, and we could try to make the autodetection smarter (somehow?) to figure out which desktop environment the user uses and pick the more appropriate one. This does presume that there is some stable ABI we can rely on which I'm not sure is something we can depend on since C++ is notorious for NOT providing a stable ABI. (But if we assume we are probably only targeting Unix/Glibc platforms, maybe this can sneak by assuming Qt itself is stable enough in terms of ABI.)
And this of course is predicated on whether I can make Experiment #42 reliable. (There is a crash I need help with.)
Thanks. Support for KDE is very important to me, but I also had some troubles to integrate this library with my builds (it does not use CMake and I am not a C/C++ expert). So it was easier for me to write a similar library in Rust, with support for both Qt and Gtk (link). The issue is that at the moment I also have to determine at compile time which library will be used for Linux. I was also planning to add support for dynamic linking to solve this issue so I will follow this attentively.
Regarding how to pick the environment, I asked a SO question. There does not seem to be a reliable way yo do it. By checking the xdg-util source code, I decided to settle on checking the environment variables to guess the desktop environment and then use Qt for KDE and LXQt, otherwise GTK.
I'll share my view on KDE file dialog support here.
KDE is a framework that factors in building, library loading and even an IDE. It has a dual license scheme that may or may not be compatible with NFD.
I have stayed away from KDE because it would take a KDE expert to extract the functionality we need and keep it in line with the current build system.
KDE also targets all 3 of the same desktop OSes that NFD does. Supporting KDE dialogs across all of them would complicate the build system interface for people who Just Want A Damn File Dialog.
For these reasons, a KDE backend is unlikely. But if someone who is a KDE expert comes along and proves me wrong, I would take a serious look at their example.
Thanks for your reply. I am not an expert in this area but I thought that the cross-platform framework was Qt and KDE was a Linux-only desktop environment that could be autodetected instead of complicating the interface. I didn't want just a file dialog, but a native file dialog in the sense that it matches the user's expectations. As stated in my previous message, I ended up writing my own implementation so this issue is no longer a priority for me, but it would still be nice to have.
KDE also targets all 3 of the same desktop OSes that NFD does. Supporting KDE dialogs across all of them would complicate the build system interface for people who Just Want A Damn File Dialog.
Supporting KDE on linux would be totally enough. I have never ever bumped into anyone using KDE on MacOS or Windows which signals userbase being simply too low to be of any significance. Besides such users would still be able to use this library and get native file dialogs provided by the OS. Totally good enough for extremely non-standard systems.
I would also like to say that current GTK backend sucks as well. It is fine on GTK-based desktops where library version matches that used of this library, but ends up being total disaster on Qt-based desktops. It is GTK's fault of course. Another reason to which i bumped into is that gtk backend requires linking to a library that may or may not be present on the system. It gets even uglier with build bots in some configurations.
You mentioned somewhere else possiblity of "nfd_zenity" backend. I think this is perfect approach for linux. It also opens possibility to implement KDE support with the help of kdialog as well. Due to very reasons i already listed i implemented kdialog/zenity backends selected at runtime. I am not submitting PR just yet as i suspect my implementation may feel too heavy for your taste (judging from current library code). Nevertheless please take a peek and see if there is anything useful for nfd: https://github.com/rokups/nativefiledialog/commit/fe7d3335b1566fd7846dceda1d44ec2e1fa088be
Hey,
kdialog, implemented on Linux, sounds interesting. I have not worked with kdialog myself. The devel branch supports an implementation of the Zenity backend already.
Regarding the approach taken in the linked code, we would want to avoid linking the STL, and ideally stick to C99 where possible.
The status of KDE support:
I am willing to accept a kdialog PR that meets the standards laid out in https://github.com/mlabbe/nativefiledialog/blob/master/docs/submitting_pull_requests.md
Having switched from GNOME to a KDE (Plasma) based distro I have also wanted to see support for KDE, so I began implementing my own, based on the kde_zenity.c source. Currently I only need to open single files, so only NFD_OpenDialog works at the moment. But it's a promising proof of concept. It uses the command strings kdialog, --getopenfilename, --title=Open File.
Kdialog looks like the way to go. Its shell scripting syntax is a lot like Zenity so deriving from it looks straightforward. I'm still trying to figure out how it applies filters for several file types as their documentation isn't very clear for lists of types. (would rather use file name extensions for consistency, rather than the MIME file standard)
@ccajas I am supportive of this effort continuing to be built by the community. If you can link to a PR containing your changes perhaps someone else would be interested in filling out your work until it is ready.
Just passing by but I noticed this, and this looks very much the wrong way to open a file dialog box on linux, regardless of the desktop environment. Both GTK and KDE (and others) support the DBUS freedesktop spec for file dialog boxes, see here for that API. You can just call the FileChooser in the dbus desktop portal and whatever desktop the user has running will open a file dialog box (open or save as you request, a variety of options are able to be passed in via the variant map as well if you wish to constrain to specific file extensions or whatever else).
In short just access the local session dbus port, call with the service name of org.freedesktop.portal.Desktop on path /org/freedesktop/portal/desktop and using the object name of org.freedesktop.portal.FileChooser call the appropriate method of OpenFile/SaveFile/SaveFiles with the appropriate arguments (parent window or none if you don't want it parented, the title, and the variant map of options), and you'll get the reply handle back, just wait for a reply on it (poll it every once in a while or so) until you get a response, which will contain whether it was successful, the file path if an openfile or the success result on save file(s).
This will handle KDE, GTK, and others, basically any DE that follows the freedesktop spec (all of them? or at least all the bigger ones) and will open their native file handling dialog for whatever that may be for them, and you won't need to link to anything odd like kde/gtk or anything at all nor will you have to shell out to another program and then have to worry about cleaning it up properly and other such related issue.
Also, another bonus with following the freedesktop spec, open dialog's will also work even if the application is running sandboxed, like via snap/flatpak or so for the people that use those, where if you just call for an open dialog box functions directly in the kde/gtk/etc API's then it will not have access to any user allowed files.
While this is the cleaner solution, would there be any concern about the freedesktop portals not being installed on the user's system? There are questions like this one which suggest that not all users have the portals on their systems - not sure if this solution would impact usability.
Also, freedesktop portals seem to be a relatively new feature - it was only introduced 5 years ago, and was released as a standalone thing (i.e. without expectation that snap/flatpak is also used) even more recently.
I am pretty sure one or the other portal is guaranteed to be installed. For example kde portal is required by plasma-meta package. Portals are not exactly old thing though. This library predates existence of portals. Maybe a parallel dbus-based implementation would be a good idea if support for ancient systems is desired.
While this is the cleaner solution, would there be any concern about the freedesktop portals not being installed on the user's system? There are questions like this one which suggest that not all users have the portals on their systems - not sure if this solution would impact usability.
Can fall back to other methods. If they don't have a freedesktop portal (are there any DE's that don't that are still active?) then I'm not even sure what you could even call out to at that point.
Maybe a parallel dbus-based implementation would be a good idea if support for ancient systems is desired.
Yep, manually calling out to things at that point could be warranted, each option should probably be behind feature flags though, like I'd probably want to only compile with dbus support, I don't want to be linking in random other things when possible.
Can fall back to other methods. If they don't have a freedesktop portal (are there any DE's that don't that are still active?) then I'm not even sure what you could even call out to at that point.
Well, I just learnt that my friend's recently installed Arch Linux doesn't have working portals (in the sense that Firefox doesn't open the dialog if you use GTK_USE_PORTAL=1), even though all other applications open some workable file chooser (i.e. the one baked into the application). So it definitely shouldn't be assumed that all active DEs come with the portals.
Archlinux is not exactly something that sets a precedent for common desktop distributions. Arch by default does not come with anything related to desktop. Ubuntu/fedora/mint/manjaro should be ones that set the precedent.
On October 22, 2021 07:42:59 Bernard Teo @.***> wrote:
Can fall back to other methods. If they don't have a freedesktop portal (are there any DE's that don't that are still active?) then I'm not even sure what you could even call out to at that point. Well, I just learnt that my friend's recently installed Arch Linux doesn't have working portals (in the sense that Firefox doesn't open the dialog if you use GTK_USE_PORTAL=1), even though all other applications open some workable file chooser. So it definitely shouldn't be assumed that all active DEs come with the portals. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.