rfd
rfd copied to clipboard
PolyMeilex
Replace GTK with zenity and kdialog
Gtk is a fallback for xdg portal anyway, we don't care about it much, so we can just replace it with CLI alternatives. Same for message dialogs. It would not be behind a feature flag, it would rather be a fallback for existing portal backend.
Those are also a part of most common flatpack runtimes so we should get a working message dialog even from a sandbox.
Just because GTK is installed doesn't mean zenity is installed, and likewise just because Qt or KDE is installed doesn't mean kdialog is installed too. Though it is likely that the XDG Desktop Portal is installed and zenity/kdialog would only be fallbacks. With GTK there is a check that the runtime dependency is available at build time, which wouldn't be the case with zenity/kdialog, but that's already not the case for the XDG Desktop Portal.
I do like that this would allow for simplifying the documentation and downstream developers wouldn't have to worry about making a choice between the features. Overall I'm in favor of this, but it's good to note that just because it builds doesn't mean the resulting executable will always work on someone else's machine.
Yep, indeed we can't be sure that zenity or kdialog is there, but then it's a case of lack of a fallback for a fallback, I don't care about such extreme cases. We would have a portal solution and non portal one, that's definitely enough.
My main motivation is that GTK is a UI toolkit, and is designed to take over the flow of the whole program, we as a library obviously can't let it do it, it is also non-thread safe which requires even more hacks, So I would rather just replace it with super simple async stdout read from a subprocces. I'm not even starting on the topic that GTK backend would have to be ported to GTK4 someday, which would be a nightmare. Portals in contrast are a pleasure to work with, thread-safe and async by default, same would go for zenity/kdialog subprocesses. This would also reduce the amount of unsafe to 0.
I already stated POC implementation to see if it is good enough for a fallback, and so far it works nicely.
I'm not even starting on the topic that GTK backend would have to be ported to GTK4 someday, which would be a nightmare.
Ah, I hadn't even thought about that with regards to this library. Yeah, considering the maintenance cost of that, getting rid of GTK seems like a good idea for the long term maintainability of this library.
The (Async)MessageDialog structs were only implemented on Linux with GTK. How do you plan to handle that? I would still suggest moving them to a separate library. I kinda doubt there's much of a need for those; I think Rust GUI libraries should be able to make their own message dialogs. By contrast, file dialogs are quite complex and users like to use the platform file dialog they are accustomed to.
The (Async)MessageDialog structs were only implemented on Linux with GTK. How do you plan to handle that? I would still suggest moving them to a separate library. I kinda doubt there's much of a need for those
I would just call zenity/kdialog, It's easy to just add it as a dependency in any package manager and on Flatpak zenity is just available out of the box in org.freedesktop.Platform.
That works, though the zenity/kdialog dependency needs to be clearly documented if (Async)MessageDialog is used.