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. They're the first to deviate from them if it suits them, or else we end up with contraptions like a complete unix-style tree behind a prefix like /Applications/Xcode.app/Contents/Developer/... or /Library/Developer/CommandLineTools/ and a bunch of symlinks set up to point in there. To complement Ian's quote: when in Rome, do as the Romans do ... but don't try to be more catholic than the pope ;) Unless you want to ship KDE applications through the App Store, but in a way I hope that's never going to happen. R.
