[KDE/Mac] Multiplatform frameworks

Ian Wadham iandw.au at gmail.com
Sat Feb 28 11:00:07 GMT 2015


Hi René,

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?

Esprit d'escalier.  We could change GenericDataDir in QStandardPaths to be:

     "~/Library/Application Support/Qt5", "/Library/Application Support/Qt5"

That would work for ALL applications that use Qt5 and QSP, regardless of origin,
and would be a more "correct" usage of Apple OS X by the Qt 5 libraries.

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

I was thinking the same.  I come from an environment where everything had to be "uniquified":
large databases with thousands of application programs.  And we already have the example,
in Open Source and Macports, of ECM being an ambiguous acronym… ;-)

Cheers, Ian W.





More information about the kde-core-devel mailing list