Re: Questions about a unified API for file choosers (and platform/toolkit integration)

Simon Lees <[email protected]> Mon, 27 Mar 2017 13:01:23 +1030
Newsgroups	gmane.linux.xdg.devel
Message-ID	<[email protected]>

On 03/24/2017 08:00 AM, Roman Hargrave wrote:
> 
> 	First off, I do hope this is the correct mailing list seeing as it's the 
> one cited as being for general inquiries on freedesktop.org.
> 
> Having got that out of the way, I was curious as to whether there had been any
> discussion on a manner of general-purpose interface for file selector dialogs,
> as they are one of the more frequently interacted-with non-control aspects of
> the toolkits (GTK2/3, Qt, Wx, Enlightenment, etc..) in use today in building
> applications and desktop environments on Linux.
> 
> This question first came to mind when GTK3 replaced the type-ahead feature with
> a recursive search, at which point it became apparent to me that I would not 
> like to have to interact with that particular file chooser anymore.
> 
> Unfortunately, due to the nature of file choosers and their toolkits, the user
> is at the mercy of the toolkit developer, and GTK has decided that any ability
> to change this behavior shall not be considered for inclusion.
> Also, unfortunately, many very useful applications using these toolkits really
> have no alternative (Gimp, Inkscape), and working on an alternative would be
> counterproductive, to boot.
> 
> Currently, some applications use DESKTOP_SESSION as a way to determine which 
> utilities and IPC facilities, etc, to interact with. Currently, the burden of
> selecting the "correct" toolkit features is upon the application, and I have 
> encountered at least one application that seems to switch between the Qt or
> GTK file picker based on the environment it runs in, so there is that.
> 
> Now, if there were a toolkit-agnostic set of interfaces for applications
> to call in to in order to prompt the user with the native file picker
> instead of that which the toolkits use would have the advantage of insuring
> that any settings applied by their desktop environment follow through to the
> application experience, thus allowing users to, for instance, not be subjected
> to, for instance GTK file picker if they would prefer to use the Qt picker.
> 
> It would also allow for users to more efficiently use applications which have
> an anemic file chooser by way of their toolkit (some older versions, i think, of 
> fltk just present a listbox of files in PWD) - provided that the application
> uses the interface rather than calling directly in to the toolkit.
> 
> I would be interesting in writing an RFP if one does not already exist for such
> a thing, but was also primarily interested in fielding interest, as I know that
> there would probably be interest in being able to use a "better" (in some folks
> opinion) picker than say, the GTK picker, given what I've read in the rather
> heated discussions on the GTK and Gnome bugzilla.
> 
> I don't intend to attract ire from more seasoned XDG/Freedesktop folks, as I know
> Freedesktop isn't exactly a standards org, but it does seem like the most appropriate
> venue, to me at least.
> 
> Feel free to point me elsewhere if you know of a better group for this.
> 

There is a xdg-file-dialog, to go with xdg-terminal and friends but it
seems to only support kde and zenity (gtk?) this seems close enough to
what your looking for it would just be a matter of getting toolkits to
use it rather then there own built in. Although you would probably want
to extend some other areas as well for example there's currently no
sensible option for enlightenment or lxqt.

-- 

Simon Lees (Simotek)                            http://simotek.net

Emergency Update Team                           keybase.io/simotek
SUSE Linux                           Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

_______________________________________________
xdg mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/xdg
signature.asc (application/pgp-signature, 488 B)