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

[Roman Hargrave]

On Tue, 28 Mar 2017 10:37:47 +0100
Emmanuele Bassi <ebassi at gmail.com> wrote:

> On 27 March 2017 at 22:21, Thiago Macieira <thiago at kde.org> wrote:
> > On segunda-feira, 27 de março de 2017 13:38:39 PDT Roman Hargrave wrote:  
> >> 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.
> 
> -- 
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> 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.

-- 
Roman Hargrave
http://hargrave.info
roman at hargrave.info

$ fortune -s linuxcookie linux cookie
When a float occurs on the same page as the start of a supertabular
you can expect unexpected results.
		-- Documentation of supertabular.sty