[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: QStandardPaths::GenericDataLocation on MacOS
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2018-05-03 19:09:03
Message-ID: 2341409.ageFNPuFvH () bola
[Download RAW message or body]

> 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.

> > Unix does support installing software to any prefix
> > (because it provides a way to customize lookup).

More importantly, the Unix QSP are relative to Qt's install prefix (if memory serves \
me well; and my patched version is too).

> > concern that this could cause problems for monolithic (macports-style)

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 (and in practice MacPorts installs its .app bundles under /Applications, \
not under $prefix ;))

> improving speed as it eliminates the large number of small files) then
> we can also ensure the icons are kept compressed on disk.

Doesn't Kate already get its icons from the qresource?

> > 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. 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...

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.

Cheers,
R.


[prev in list] [next in list] [prev in thread] [next in thread]