I'm using Geany 1.38 in an Arch system with a LXQt DE and I would like to use the LXQt file chooser, which it's possible if the application uses [XDG desktop portal](https://flatpak.github.io/xdg-desktop-portal/#gdbus-org.freedesktop.portal.F...).
Geany is a GTK application, it is not a sandboxed application (and many things it does that are a normal part of being an IDE are not allowed in sandboxes IIUC) and so it has no need for and does not use portals.
I'm not expert about sandboxed applications, I just see that if an application supports portal with one of its implementations it works having DBus as the only dependency (no need to use flatpak/libportal), which now I see Geany doesn't have.
Geany also works on Windows and Macos and on many other DEs which don't seem to be listed as having backends [here](https://github.com/flatpak/xdg-desktop-portal). Also not sure if Windows and Macos do dbus even.
Therefore supporting portals would require Geany to have two builds, one using portals and one using GTK with the associated maintenance and support.
GTK4 (if Geany ever gets there) has a [native](https://docs.gtk.org/gtk4/class.FileChooserNative.html) file chooser for Windows and Macos, but not Qt (can't think why not ;-)
Geany also works on Windows and Macos and on many other DEs which don't seem to be listed as having backends [here](https://github.com/flatpak/xdg-desktop-portal). Also not sure if Windows and Macos do dbus even.
Maybe I forgot the "on Linux" bit, not for use on other platforms where it could be either native (better) or just GTK 😝
Therefore supporting portals would require Geany to have two builds, one using portals and one using GTK with the associated maintenance and support.
Right, unless making portal/dbus mandatory deps on Linux/BSD, which is not the case. macOS and Windows builds can still build as usual though.
GTK4 (if Geany ever gets there) has a [native](https://docs.gtk.org/gtk4/class.FileChooserNative.html) file chooser for Windows and Macos, but not Qt (can't think why not ;-)
That wouldn't help me as Linux user anyway, don't need a Qt implementation directly having portal, it can use any implementation using any toolkit depending on what the user wants
Closed #3458 as completed.
GTK4 (if Geany ever gets there) has a [native](https://docs.gtk.org/gtk4/class.FileChooserNative.html) file chooser for Windows and Macos, but not Qt (can't think why not ;-)
Actually, the native file chooser is indeed for Qt if the app calling it is run on Plasma or another Qt environment. The "native file chooser" just calls out to the XDG portal. And GTK3 already has that API as well.
The main issue with native dialogs/portals, is that they have reduced feature set, see e.g. [GtkFileChooserNative](https://docs.gtk.org/gtk3/class.FileChooserNative.html). And some might be a problematic trade-off for our use cases. Also note that I can't read anything in the link above about the portals being used outside of a sandboxed app, so I'm not sure if it would happen.
Hopefully this can be implemented in the future. I have to say that I have gotten used to GUI applications on Linux to support portals for open/save dialog.
I'm using this on Fedora+KDE+Wayland for example with Evolution, Visual Studio Code and Joplin. All are installed "native" (RPM). No sandboxing (Flatpak, Snap, Toolbox container). One is a GTK application, the others are Electron-based. In all cases I just set the environment variable "GTK_USE_PORTAL=1" and the applications automatically use the KDE open/save dialog. Also most Flatpak applications that I have installed support this. Any program that shows the GTK/GNOME dialog these days feels a bit out of place on my desktop and can sometimes disrupt the workflow.
Anyway Geany looks like a really good editor. I will definitely check it out more. Always on the lookout for alternatives to VSCode. Thanks for all the hard work putting into it.
@paidhi "somebodys" got to create a pull request to show it works, and given (almost?) none of the Geany devs use non-GTK based distros its probably unlikely to be them.
They also need to address the point @b4n made above, Geany adds functionality to the file chooser to provide a filter based on Geany filetypes, the ability to select the encoding to be used to open the file, and the ability to choose the filetype to use for the file (important if auto detection is wrong). AFAIK those can't be added to native filechoosers.
I believe #3861 would solve this (albeit behind a preference), wouldn't it?
AFAICT #3861 hasn't been tested with portals, just native, but GTK says it can work, so maybe "somebody" could try it.
@elextr AFAICT it's basically the whole point for this on Linux, otherwise the "native" dialog is usually GTK's.
IIUC in theory the portals thingy would make it the KDE dialog on KDE, thats what needs testing.
I'm using Plasma, so I'll do a test build with the referenced PR. I'll even make a PR for the Flathub package so that the Flathub bot will build a package for others to easily test as well.
In my personal opinion, I think that the functionality that is added to the GTK file chooser is not worth very much. You can change the encoding and the filetype after opening a file, and for people who dislike GTK's file chooser, having to deal with that just to get those two features--and a lot of folks won't even use them *at all*--is very much not worth it. So I like how the referenced pull request is looking, especially since it does provide an option so people can make that decision. I'm sure there are some users, even on non-GTK environments, who will prefer to decide a file's encoding and filetype *before* opening the file.
This will be helpful even on GNOME; they already have a LibAdwaita-based file chooser, and they're working on a Nautilus-based file chooser. This will likely serve as guidance for other GTK-based environments to create file choosers based on their primary file managers.
Note that the flathub Geany package is not made by this project despite the "by Geany Team", note the "unverified" on it, so we have no control over what they do.
You can change the encoding and the filetype after opening a file,
The user can't change the encoding used to __load__ the file after its loaded, that will have no effect, changes to encoding afterward are just for saving.
And having the wrong filetype may have significant effects as more filetype specific plugins are added, starting with LSPs real soon now.
So those options are important in specific cases. Of course they don't matter to users who are always UTF-8 and use the right extensions (eg not .h for C, ducks :-) but anyone can find an olde piece of code on the interwebs that they want to look at or use.
Thanks for the offer to test, let us know what the KDE chooser is.
I juste tested #3861 with this, and it almost works. The GTK4 portal implementation my OS used doesn't like empty filters, but if the code is updated to not add those it seems to work from very minimal testing.
@b4n on KDE?
@elextr no, but given @paidhi said it worked for other apps I guess he has a portal implementation that would be triggered given the GTK4 one can be. Of course it might have oddities like the GTK4 one that seems to dislike empty filters although no documentation seems to suggest it's invalid (merely not very useful), but apart from that it "should work". But easy enough: just test #3861 and see.
@b4n @paidhi said it worked with __other__ GTK apps, not #3861
just test https://github.com/geany/geany/pull/3861 and see.
Indeed __"somebody" with KDE__ should test.
If nobody does in a reasonable time then it should not stop this being merged if it works fine on the platforms we can test.
@b4n @paidhi said it worked with **other** GTK apps, not #3861
Yes, but given my test invoked the portal, it's implementation should matter little.
If nobody does in a reasonable time then it should not stop this being merged if it works fine on the platforms we can test.
I don't think this should block #3861 either way, it's not its primary goal so we can always tweak for portal quirks in a second time.
PS, how did you test with GTK4, have you ported Geany to GTK4 and not told us??
The portal implementation that popped up for me was GTK4, not Geany.
I don't think this should block https://github.com/geany/geany/pull/3861 either way, it's not its primary goal so we can always tweak for portal quirks in a second time.
Agree, perhaps it wasn't clear that "this" in "not stop this being merged" above referred to #3861
Sorry it took me a while to get back to this.
First, I am the maintainer of the Geany Flathub package. Someone put it up a long time ago, then they disappeared, then I took up the torch. I agree that the current situation in how Flathub does not clearly display the disconnect between the developers of the software and the maintainers of the package is far from ideal, but [discussions on how to improve that have stalled.](https://github.com/flathub-infra/website/issues/3131) I'm pretty sure all I can really do is amend the readme that appears on the Flathub page, and it may also appear in various software centers. That doesn't really adhere with best practices, but I'm not sure I really care about that very much??? There's no situation where Geany will ever appear in Flathub's banner; it's not a GNOME app.
Anyways, you can see that I mentioned this issue and the PR in a PR against Flathub's Geany repo. If you want to use Flatpak to test #3861, that option will soon be available to you. 🙂
Second: I can confirm that after building Geany with the git tree from the pull request, the relevant option appears in the Miscellaneous section, and it does cause Plasma's file chooser dialog to appear for all file opening and saving operations. The filters work too, and even an empty filter doesn't seem to cause much trouble. @b4n your DE has a GTK4 portal? Would that be GNOME or Pantheon? I know GNOME's working on a Nautilus chooser, but that's probably not ready yet. You probably want to file an issue with their xdg-desktop-portal; I don't think empty filters are actually invalid.
github-comments@lists.geany.org