On Thu, 03 May 2018 21:09:03 +0200 René J.V. Bertin <rjvber...@gmail.com> wrote: > >On Fri, May 4, 2018 at 2:38 AM, Thomas Friedrichsmeier > > >> 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 > > No, that shouldn't happen, and it doesn't with the official Kate > bundle. Standalone & self-sufficient also implies that you don't > clash with another similar application, or even with another copy of > yourself. Bundling DBus within such a standalone app bundle and > running it from there would of course be asking for trouble, but it > would also make no sense at all.
Again, this is about QStandardPaths::GenericDataLocation, exclusively. _If_ applications were to actually install to the current paths defined for that on Mac "Library/Application Support", and "~Library/Application Support", on more, no less, _then_ clashes would start to happen. As far as I am aware, _none_ of the current installation approaches for KF5 does so, and as a consequence they all fail GenericDataLocation lookup with an unpatched qt. Which is one reason why I don't think "just install to the offical path, then" is an acceptable solution. Current kate "standalone" is not a good example, because it is _circumventing_ any QStandardPaths::GenericDataLocation lookup problems by shipping all its data compiled in. If it did not, it would fail to find its data files with an unpatched qt, despite following documented code patterns. > I think you're misusing the term monolithic here? Standalone > appbundles are monolithic, an aggregate framework bundle containing > all KF5 frameworks would be monolithic too. Installing under a prefix > that isn't the root is not what I'd call monolithic I don't care what it's called, I just need some terms to refer to this. My monolithic, here, was referring to _all_ in one place, instead of one app and its dependencies in one place. And yes, standalone bundles are not really all that different from "monolithic" installs, technically, except, it would be a typical situation to have more than one of them at the same time. > (and in practice > MacPorts installs its .app bundles under /Applications, not under > $prefix ;)) Ah, good reminder. But it doesn't install anything under /Library, does it? Which is why MacPorts, too, cannot support KF5 with a non-patched QStandardPaths, right? > >> Why would that be a problem? If something is written to the > >> writable > > It's not a problem if you don't care where those files are written. I don't care where files are written at runtime (as long as they can be found again). I would like not to care about where files are written at installation time, but the sad fact is they will not be found unless installed to one specific absolute path. > But if that's true, the whole issue can probably be avoided by > determining the install locations for (shared) resources from QSP > instead of hardcoding them in CMake files... Nope. That will simply lead us into the situation discussed near the top of this mail. Besides, _if_ we are both talking about the option of using an _unpatched_ Qt, then hardcoding or querying QSP makes very little practical difference. I understand you'd like to see ECM to continue to support your "Unix-like" patched QSP, and why not? ECM is under "our" control anyway, but the issue at hand is one that cannot be solved in ECM alone. > 1 problem here: ApplicationsLocation. On Mac that points > to /Applications (probably still without a test version - danger!), > which is not at all comparable to what ApplicationsLocation is used > for elsewhere. True. Any code that relies on this will likely fail on Mac _and_ Windows, so that's a valid concern. Yet, arguably, its typically going to be a milder failure, and clearly, the prevalence is much lower (check GneericDataLocation vs. ApplicationsLocation on lxr.kde.org). So let's keep it in mind, but not make it a key concern while looking for a path forward. (And in fact, I'm a bit at a loss to see how to solve _that_, short of, again, installing everything to a single absolute location.) Regards Thomas
pgps7D0cMeK5z.pgp
Description: OpenPGP digital signature
