On Tue, 28 Mar 2017 10:37:47 +0100 Emmanuele Bassi <[email protected]> wrote:
> On 27 March 2017 at 22:21, Thiago Macieira <[email protected]> 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 > [email protected] > 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 [email protected] $ 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 _______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
