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

[Roman Hargrave]

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.

[Thomas Kluyver]

Post by Roman Hargrave
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.

Flatpak has a system of 'portals', so that a sandboxed application can
ask the user to select a file which the application wouldn't otherwise
have access to. From the description, it sounds like the UI you see will
depend on your desktop environment, not on the application's toolkit,
which seems like what you want.

https://github.com/flatpak/flatpak/wiki/Portals

I don't know whether this interface is available to applications not
running in Flatpak, though.

Thomas

[Roman Hargrave]

On Sun, 26 Mar 2017 14:10:25 +0100

Post by Thomas Kluyver

Post by Roman Hargrave
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.

Flatpak has a system of 'portals', so that a sandboxed application can
ask the user to select a file which the application wouldn't otherwise
have access to. From the description, it sounds like the UI you see will
depend on your desktop environment, not on the application's toolkit,
which seems like what you want.
https://github.com/flatpak/flatpak/wiki/Portals
I don't know whether this interface is available to applications not
running in Flatpak, though.
Thomas
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

This is the general idea, yes, minus the sandbox portions (e.g. moving the file
in to the sandbox when selected, and whatnot). For the reason that these are not
so much for toolkit-agnostic operation (that's just a convenient side-effect) but
so that applications don't have as much control over file-related things.

That being said, I think that for non-sandboxed (e.g. non-flatpak)
applications, a linkable API would be preferable to the session bus-based solution,
just for simplicity, even though dbus and friends are omnipresent (I even found
it on an old embedded ebook reader, in some form).

[Thomas Kluyver]

Post by Roman Hargrave
even though dbus and friends are omnipresent (I even
found
it on an old embedded ebook reader, in some form).

Was that a Kobo device, by any chance? I've got one of those to
experiment with, and also noticed that it starts dbus.

[Roman Hargrave]

On Sun, 26 Mar 2017 21:58:05 +0100

Post by Thomas Kluyver

Post by Roman Hargrave
even though dbus and friends are omnipresent (I even
found
it on an old embedded ebook reader, in some form).

Was that a Kobo device, by any chance? I've got one of those to
experiment with, and also noticed that it starts dbus.
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

Actually it's a kindle k4.

It's runs a more true-to-desktop style Linux install than my android phone...

[Simon Lees]

Post by Roman Hargrave
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.

[Roman Hargrave]

On Mon, 27 Mar 2017 13:01:23 +1030

Post by Simon Lees

Post by Roman Hargrave
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-file-dialog is the idea here, but it doesn't offer a native solution,
which I think would be more appreciated by some developers.

When I get some time I'll write a quick C example, provided I don't get
distracted.

[Matthew Paul Thomas]

Post by Roman Hargrave
…
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.
…

I understand the desire to swap out one toolkit’s file picker for
another. However, many apps legitimately embed custom UI into the file
picker. For example:

* LibreOffice’s Open dialog includes a “Version:” menu for opening
versioned documents. The contents of the menu changes dynamically
to list the versions of the selected document, and it is disabled
whenever the document has only one version.

* LibreOffice’s Save dialog includes a “Save with password” checkbox.
The checkbox becomes disabled and unchecked whenever you choose a
file format that doesn’t have that feature.

* Gimp’s Open dialog includes a list of image formats so that you can
override the auto-detected format if necessary.

* Geany’s Open dialog includes menus for manually specifying the
encoding as well as the filetype.

If any “toolkit-agnostic set of interfaces” was not capable of these
things, developers of apps like these would have to not use it, drop
features, or resort to a separate dialog before/after the file picker,
annoying all users for the sake of a few.

On the other hand, if any set of interfaces *was* capable of these
things, it would be similar in complexity to a toolkit. So app
developers would need to learn — and maintain code in — one toolkit plus
one quasi-toolkit, when they could be spending that extra
learning+maintenance time on features or bug fixes instead.

[Ingo Ruhnke]

Post by Matthew Paul Thomas
or resort to a separate dialog before/after the file picker,

Gimp does that when you export an image. In the file dialog you just
select the format and the filename and in a dialog shown after you hit
"Export" you get to chose file type specific settings (compression,
interlacing, gamma, etc.). Works pretty well.

Also let's not 'perfect be the enemy of good', just because a solution
wouldn't work every time, doesn't mean it couldn't work most of the
time. File dialogs are really not that different in most applications
or even across operating systems.

Post by Matthew Paul Thomas
annoying all users for the sake of a few.

Having a different file dialog in every app is annoying *all* users,
not just a few.

Post by Matthew Paul Thomas
On the other hand, if any set of interfaces *was* capable of these
things, it would be similar in complexity to a toolkit.

The file dialog wouldn't need to be a toolkit itself, all it would
need to do is provide a way to embed a custom widget of another
toolkit in it. I haven't seen anybody sticking a Qt widget inside a
Gtk app, but that should be something doable.

That said, I think it's a little late for a regular old file dialog
API, it could have been really useful 15 years ago, but we are slowly
moving away from apps that have full system access. So something like
Flatpak's Portals seem to be a more realistic way forward.

[Roman Hargrave]

On Mon, 27 Mar 2017 13:21:05 +0200

Post by Ingo Ruhnke

Post by Matthew Paul Thomas
or resort to a separate dialog before/after the file picker,

Gimp does that when you export an image. In the file dialog you just
select the format and the filename and in a dialog shown after you hit
"Export" you get to chose file type specific settings (compression,
interlacing, gamma, etc.). Works pretty well.
Also let's not 'perfect be the enemy of good', just because a solution
wouldn't work every time, doesn't mean it couldn't work most of the
time. File dialogs are really not that different in most applications
or even across operating systems.

Post by Matthew Paul Thomas
annoying all users for the sake of a few.

Having a different file dialog in every app is annoying *all* users,
not just a few.

Post by Matthew Paul Thomas
On the other hand, if any set of interfaces *was* capable of these
things, it would be similar in complexity to a toolkit.

The file dialog wouldn't need to be a toolkit itself, all it would
need to do is provide a way to embed a custom widget of another
toolkit in it. I haven't seen anybody sticking a Qt widget inside a
Gtk app, but that should be something doable.
That said, I think it's a little late for a regular old file dialog
API, it could have been really useful 15 years ago, but we are slowly
moving away from apps that have full system access. So something like
Flatpak's Portals seem to be a more realistic way forward.
--
Blog: http://grumbel.blogspot.com/
ICQ: 59461927
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

WRT moving towards flatpak, I realize that some people want that to be the direction
things go in, but I personally dislike it, as do many others. For this reason,
I think that there is still merit to working on plain-old-userspace API's.

[Thiago Macieira]

Post by Roman Hargrave
WRT moving towards flatpak, I realize that some people want that to be the
direction things go in, but I personally dislike it, as do many others. For
this reason, I think that there is still merit to working on
plain-old-userspace API's.

The flatpak/AppImage/etc. concept is incompatible with the way that Qt
integrates with the system (by way of plugins installed by the system), so at
this time we wholly discourage our users from using those solutions.

[Emmanuele Bassi]

Post by Thiago Macieira

Post by Roman Hargrave
WRT moving towards flatpak, I realize that some people want that to be the
direction things go in, but I personally dislike it, as do many others. For
this reason, I think that there is still merit to working on
plain-old-userspace API's.

The flatpak/AppImage/etc. concept is incompatible with the way that Qt
integrates with the system (by way of plugins installed by the system), so at
this time we wholly discourage our users from using those solutions.

Flatpak is not *at all* the same as AppImage, and there's KDE runtime
for Flatpak that already includes Qt, and a portal implementation that
allows GTK+ applications running under KDE to use a native file
selection dialog to open files from the sandbox:

https://community.kde.org/Guidelines_and_HOWTOs/Flatpak

Ciao,
Emmanuele.

[Roman Hargrave]

On Tue, 28 Mar 2017 10:37:47 +0100

Post by Emmanuele Bassi

Post by Thiago Macieira

Post by Roman Hargrave
WRT moving towards flatpak, I realize that some people want that to be the
direction things go in, but I personally dislike it, as do many others. For
this reason, I think that there is still merit to working on
plain-old-userspace API's.

The flatpak/AppImage/etc. concept is incompatible with the way that Qt
integrates with the system (by way of plugins installed by the system), so at
this time we wholly discourage our users from using those solutions.

Flatpak is not *at all* the same as AppImage, and there's KDE runtime
for Flatpak that already includes Qt, and a portal implementation that
allows GTK+ applications running under KDE to use a native file
https://community.kde.org/Guidelines_and_HOWTOs/Flatpak
Ciao,
Emmanuele.
--
https://www.bassi.io
_______________________________________________
xdg mailing list
https://lists.freedesktop.org/mailman/listinfo/xdg

Regardless, concentrating on packaging/runtime systems' support for such a feature is
tertiary, and detracts from the overall idea and discussion.

Since packaging solutions are another layer, implementing such a thing exclusively in
them is not the best way to solve a problem since it not everyone is installing things
with your solution. Some people are using RPM/DPKG style systems, others might compiling
a small application and installing it locally.

The current mainstream packaging packaging solutions have been around for a very long time
and a lot of people don't take time to hand-assemble a package for the software that
they just compiled. I don't see why it's going to be any different with a new tool,
even if that's what the developers want (it's what Debian maintainers want, but that
advice is not oft-heeded by end-users).

If this were implemented at a library layer, it can be smart and use the flatpak portal
if it _is_ there, otherwise it can do the thinking.

If this were implemented exclusively as a runtime feature for a distribution tool like
flatpak, it means that unless flatpak (or whatever else) has its hands in the toolkit
implementations, applications have to be aware of flatpak and interact with it in
order to use that API. That creates a dependence on flatpak, which given what it is
is a very bad thing, especially for people that want to package for another platform,
or for whatever reason can not, or do not, want to use it.

But lets not get in to the details of flatpak and friends, because it is, in my opinion,
only tangentially relevant.

[Emmanuele Bassi]

Post by Roman Hargrave
Regardless, concentrating on packaging/runtime systems' support for such a feature is
tertiary, and detracts from the overall idea and discussion.

If you allow me to be quite blunt: there is really nothing to discuss, here.

You have:

- no proof of concept code
- no draft specification
- no buy-in from toolkit developers
- no buy-in from application developers
- no actual definition on who your users that are "annoyed" by
different file selection dialogues are - no actual number on how many
of these users are there in the wild,
and what's their fraction of the total users of the impacted toolkits

What you *do* have is your own position of being annoyed by the GTK+
file selection dialogue. As much as I can empathise with your feelings
about that particular user experience (it's not the best, but there's
really no "best" that will satisfy everyone, really), there's no way
for you to state that "all users" are inconvenienced by this. A vast
majority of users won't mix and match applications and desktop
environments; and even when they do, the difference between file
selection dialogues is not so pronounced to impede use — after all,
we're talking about file selection, not quantum mechanics. There may
be impedance mismatch between Easter Egg features, like search, or tab
completion; that's unfortunate, but that's also life when your OS does
not have a single toolkit and a single UX.

You can check the archives of this mailing list for similar past
discussions — none of which resulted in a single line of code or
documentation, because the problem space is more complicated than a
simple "I want all my file selection dialogues to look the same", and
if you cannot grasp the problem space then finding a workable solution
is going to be even less likely to happen.

Ciao,
Emmanuele.

[Thiago Macieira]

Post by Roman Hargrave
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.

That's actually Qt's behaviour. It chooses, based on DESKTOP_SESSION and the
window manager you're running, which platform theme to load or fall back to.
It can be either the KDE platform theme (gets you the KDE file dialog), the
Gtk3 theme (links to libgtk-3.so and gets you whatever GTK wants for file
dialog), the "gnome" theme (no linking, just dlopens some things and tries to
guess) or the fallback which uses the built-in Qt file dialog.

I don't think we can change this. There can't be a file dialog API for Qt to
use that would circle back to Qt (chicken-and-the-egg problem). At best, we
could use a centralised "guess my environment" library so that all
applications come to the same conclusion.