On Thursday May 03 2018 15:19:33 Thomas Friedrichsmeier wrote: Hi,
>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. Also, what are the chances that this will be overhauled anyway for Qt6? >install to /Library/Application Support. But that solution has obvious >limitations that I would like to avoid, and - by analogy to Unix >_and_ Windows - are entirely avoidable. 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. >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. >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 it gets through DBus, uses the alien-looking Breeze icons and default colour palette, plus the "native" Mac widget style which makes it look like an application for the visually impaired (everything way too big). It works, but IMHO no longer has any advantages over well-established truly native competitors like BBEdit (which clocks in at 32Mb *uncompressed*). And: supposing those 88Mb are the uncompressed app bundle size, how much of that has to be duplicated in each and every app that uses the Kate kpart? >I'm absolutely aware of that. The question is simply: Would MacPorts >tolaterate a symlink from /opt/local/Resources to /opt/local/share They probably wouldn't like it, but if the dislike is strong enough it will lead to a small patch that undoes or modifies the change. Careful though, <APPDIR> should probably be something like QLibraryInfo::prefixPath and not the method from QApplication which will point to the MacOS directory inside the app bundle. >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. 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. Which reminds me that I've already suggested several times that it would be useful to rethink the build system so that it determines the install locations based on QSP (using qtpaths or a dedicated small utility). Cheers, R.
