[KDE/Mac] Multiplatform frameworks

[Ian Wadham]

Hi René,

Let me kick off by saying that I am not necessarily in favour of "doing what
the Romans do"… ;-)  And I do not like directory names with a space in them
either, but that is just an annoying detail...

I just wanted to follow up on Jeremy's experiments at the start of this thread
(and subsequently) and see whether it is really feasible to go the Apple and
QStandardPaths way and what the long-term consequences might be.

I think it *is* feasible as long as QSP adds a subdir to "*/Application Support/",
which I think it should do anyway if it to be a true Apple citizen…

On 28/02/2015, at 8:15 PM, René J.V. Bertin wrote:
> On Saturday February 28 2015 18:12:40 Ian Wadham wrote:
>> One problem is that these are NOT exactly like "~/.local/share", "/usr/local/share",
>> "~/.local/share/<APPNAME>" and "/usr/local/share/<APPNAME>" on Linux.
> ...
>> A bundle identifier is something like "org.kde.<appname>".  Actually, on my system I find:
>> 
>>   Tara:~>ls /Library/Application\ Support/
>>   Adobe/             Macromedia/        ProApps/           iLife/
>>   Apple/             Microsoft/         Script Editor/     iLifeMediaBrowser/
>>   CrashReporter/     Mozilla/           avbdeviced/        iLifeSlideshow/
>>   GarageBand/        Oracle/            iDVD/              iPhoto/
>> 
>> All are either names of organisations or names of apps from Apple.
> ...
>> Another problem is that the "/Library/Application Support" directory is not really geared towards
>> apps that share data-files with other apps.  Subdirs of GenericDataDir such as doc/, kservices5/,
>> icons/, kxmlgui5/ , mime/ and dbus-1/ would look out-of-place, since they are not apps.  Also the
>> sheer number of KDE apps would tend to crowd out names of other organisation and apps.
>> 
>> One way to solve both problems is somehow to inject an organisation-id, such as KDE/ or
>> org.kde/ into QStandardPaths, so that the generic data paths would become something like:
> 
> I think that's about the ONLY solution. How else are applications going to find shared data?
> Crowding out isn't the biggest issue, BTW & IMHO, it's the risk that we end up overwriting or otherwise interfering with stuff that's not ours but happens to be "in the way".
> 
>> But I do not know how or when this could be done.  Clearly, we cannot hard-wire that into
>> the QSP code, because there are other apps that use Qt but do not come from the KDE
>> Community.  It would be easy enough to put it into ECM modules when building KF5 or
>> Frameworks software, but then how would that info be given to QSP within *every* KF5
>> executable, GUI or not-GUI, before the first call to QSP?
> 
> Exactly: it'd put us in the same place we're now, whipping up a patch that does basically the same thing even if the exact strings (paths) are closer to the "MacOS Roman" thing (hehe, thanks Ian :))
> 
>> Ideas welcome… :-)
> 
> My idea is still that we need a patch that adds a runtime selection between "Maccy" and "Linuxy" QSPs, controlled through an AA_* flag (cf. "Icons in menus") or an argument to Q(Core)Application's ctor. The initial setting of that switch would be controlled through a preprocessor macro, which we could set somewhere in the CMake scripts but that could of course be overridden if needed. Multiple levels of control each with a default, I think that gives the flexibility we need and also the compliance with Digia's requirements (App Store rules...)
> 
> Example: KDE4's GUIEnabled argument to the KApplication ctor. It's not used the same way on all platforms, and it may not have the same default on all platforms either. On OS X it has a function, so I patched the build system and headers to link it to the CMake NOGUI token used when defining an executable. With my mods, setting that token causes a preprocessor macro to be set. The default value of GUIEnabled depends on that preproc. macro: when set, the GUIEnabled defaults to False, otherwise to True. The result is that applications defined with NOGUI will now be built such that they start as non-gui applications without changing a line in their code, unless they already happened to specify GUIEnabled themselves.
> 
> I think that's what we want, regardless of where we decide to store stuff.
> But for that I really think we have to prefer function over form. Apple's guidelines are just that, guidelines.

Macros generated at build-time and used in source code are fine and are actually
how KStandardDirs works its magic.  See [1].

Modifying Q(Core)Application's constructor might not work in all cases (e.g. QSP)
because there may be processes that do not use Q(Core)Application, even if they
use Qt.  I am thinking of klauncher5, etc.  OTOH, you could just do extra patches
for those processes...

Another possibility (an Apple way… ;-) ), is to use Custom Keys in .plist files [2].

On a "per app" basis, you can insert values in Info.plist, using an Info.plist.template
file in your CMake build (as you well know, René, but I am telling others).

On an "all of KF5/Qt5" basis, you could maybe insert values in a shared .plist file, such as:
    /Library/Preferences/<org.name>.<sharedname>.plist (global) or
   ~/Library/Preferences/<org.name>.<sharedname>.plist (per user)

Some examples;
    /Library/Preferences/org.cups.printers.plist    Host's list of known CUPS printers
    /Library/Preferences/com.apple.TimeMachine.plist    Host's backup preferences
    ~/Library/Preferences/org.cups.PrintingPrefs.plist    My CUPS printing preferences

A shared .plist could contain whatever you liked (e.g. a prefix and a base for
alternate standard paths).  It could be read, using Cocoa methods, the first time
QSP is called.

There would still be a chicken-and-egg problem of where (or if) the <org.name> is
obtained and the scope and meaning of the <sharedname>…  For example, we
could have a file at /Library/Preferences/org.kde.qt_tweaks.plist, but we would
still need a way to tell Qt libraries to look at it (or not)… :-(

Cheers, Ian W.

[1]
https://projects.kde.org/projects/kde/kdelibs/repository/entry/kdecore/kernel/kstandarddirs_unix.cpp?rev=KDE%2F4.14
[2] https://developer.apple.com/library/mac/documentation/General/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html