Hi, On Thu, 03 May 2018 16:01:46 +0200 René J.V. Bertin <rjvber...@gmail.com> wrote: > On Thursday May 03 2018 15:19:33 Thomas Friedrichsmeier wrote: > >plan is actually to get David Faure to champion a solution (whichever > >one) into Qt. > > I can be wrong, but I don't see that happening beyond his general > support.
well, let's hear him on this. > I don't see what Unix does here. /Library/Application Support is just > the OS X equivalent of $prefix/share and maybe parts of > $prefix/libexec; both are central, shared location that have a > per-user equivalent (~/Library/Application Support and > ~/.local/share). The limitations I see are purely and only related to > the way software has to be installed. Yes, it's about the installation options. It is _primarily_ about the fact that the one theorically possible installation option on Mac matches with _none_ of the major available solutions (macports, homebrew, craft). It is also about the fact that this installation option causes problems, e.g. if users are to mix MacPorts and a single-app-bundled KF5 app, or two versions of a KF5 app, or many other not-so-unlikely scenarios. Unix does support installing software to any prefix (because it provides a way to customize lookup). Windows supports installing software to any prefix (because it includes an installation-relative path in the list of paths for GenericDataLocation). Mac does not, because it lacks both (even though installation-relative paths are available in other QStandardPaths). > >It's not even hard for individual apps, today. Just compile in all > >data files as qresources, and the problem is done with. > > That may be true for resources that contain no executable native > code, but it probably won't work for libraries and plugins. Those can be handled in qt.conf (and macdeployqt auto-generates an appropriate qt.conf, for instance). That may or may not be our favorite solution, but it is an already available option (and if there is a concern that this could cause problems for monolithic (macports-style) installations, qt.conf can even be provided as a per-app qresource, which in principle, should be possible to generate, and compile into each binary, automatically. > >A fully packaged Kate is available at 88MB download for instance, > >despite including a whole bunch of frameworks. > > But with that you get a version of the application that just drops > the functionality [...] I just don't want to get into that discussion, at all, here. I absolutely see use-cases for both "monolithic" and "single app" installations. So both should be supported. Currently neither is. So the issue at hand isn't to discuss which of the two is superior, but to find out how to fix the problem affecting them both. > >Again, I think this is not an either-or situation. Both centralized > >and standalone app installations are affected by this problem, unless > >relying on .qrc files, exclusively. > > There *is* an either-or situation: work with the existing > QStandardPaths or don't. Kate.app shows that the former is not > impossible, and it has the big advantage that you do everything > in-house without modifying Qt. QRC, sing it with me. That's the whole secret, as far as I am aware: Circumventing the problem by not installing files. Since I found out about this, I sleep a lot better as maintainer of RKWard, but it still bugs me, severly, for KF5 as a whole. > Another thing: it seems that in your reasoning you have only > considered the search algorithms for finding readable locations. For > the writable locations you cannot simply append a "compatibility" > location, and in turn that means that resources generated at runtime > will later be found in "native" Mac locations because QSP will return > the first location that has the requested file. Why would that be a problem? If something is written to the writable location, it will then later be found. Sure, that's the point, isn't it. Possibly by a different application, or by a different version of the same application. Also true, but nothing new. Regards Thomas
pgp30EqsMkE4W.pgp
Description: OpenPGP digital signature
