[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths
mk-lists at email.de
Sun Dec 7 14:47:27 UTC 2014
Hi René and Ian,
On 07 Dec 2014, at 13:43 , René J.V. Bertin <rjvbertin at gmail.com> wrote:
>> It's the physicist in me, I suppose. Keep the experiment as simple as possible… Ideally,
> And the biologist in *me* knows there's no such thing as a "simple" experiment, or even one that's as simple as you'd have hoped :P
and the physicist (in me) also thinks that this is indeed a simple experiment. :)
[But a simple one which has proven to be already complicated enough.]
>> I would have gone for a KF5/Qt5 version of "Hello World!", had one been available… :-)
> Write one …
I tried to trigger that after the folks started to work on the "KF5 book” at Randa.
But there was no further response to my post  except the already mentioned post by David!
Cristian Onet from KMyMoney sent also a response to that thread, as he seems the same
need for the Windows platform.
I still think one should write a test application which would test all these different
aspects of locating the whole variety of files necessary at build and runtime.
I am sure that the KF5 book will contain some simple code examples. I guess it’s worth
checking it out, as quite some effort has been invested in it back then.
> Or create a qstandardpaths_darwin.cpp or something of the sort, but yes, I think we agree here.
Well, see my other post. I did that already.
qt5 build just fine. Qt apps are running, as tested with QtLinguist.app.
qtpaths eventually shows all the XDG_*_DIRS paths correctly:
$ /opt/kde/install/darwin/mavericks/clang/kf5-qt5/qt5/inst/bin/qtpaths --paths GenericDataLocation
$ XDG_DATA_HOME=/opt/kde/install/darwin/mavericks/clang/kf5-qt5/kde/kdegames/bovo/inst/share /opt/kde/install/darwin/mavericks/clang/kf5-qt5/kde/kdegames/bovo/inst/Applications/KF5/bovo.app/Contents/MacOS/bovo
Could not find drkonqi at /opt/kde/install/darwin/mavericks/clang/kf5-qt5/frameworks/kcrash/inst/lib/libexec/drkonqi
Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.ServiceUnknown", "The name org.kde.kglobalaccel was not provided by any .service files")
games.ui: KStandardGameAction::create( 1 = game_new , KActionCollection(0x7f90ab41e500, name = "KXMLGUIClient-KActionCollection") )
games.ui: KStandardGameAction::create( 11 = game_quit , KActionCollection(0x7f90ab41e500, name = "KXMLGUIClient-KActionCollection") )
games.ui: KStandardGameAction::create( 23 = move_hint , KActionCollection(0x7f90ab41e500, name = "KXMLGUIClient-KActionCollection") )
Action does not have the correct properties to be current: ""
games.ui: KStandardGameAction::create( 13 = move_undo , KActionCollection(0x7f90ab41e500, name = "KXMLGUIClient-KActionCollection") )
Cannot open file 'theme.svg', because: No such file or directory
Icon theme "hicolor" not found.
kf5.kiconthemes: "Theme tree: (Oxygen)"
Segmentation fault: 11
but of course bovo still fails miserably, which seems to be caused by the bovo porting bug which Ian
pointed out in another post earlier.
Now I am running the complete rebuild of whole KF5… (Which I probably wouldn’t have to, as the QSP
patch  is binary compatible, right?!)
> Maybe someone ought to have a look at port:libxdg-basedir and/or port:xdg-utils to see how well they implement the relevant xdg functionality on OS X?
Yep, that might be a good idea.
> That's only because port:kde decided to replace ~/.kde with ~/Library/Preferences/KDE, which is a so-so decision.
> ~/.kde/share/config could indeed go into Preferences, but other dirs under ~/.kde/share should go under ~/Library/Application\ Support
Well, that decision had to be made back then, as there were problems when stuff was in ~/.kde only…
Can’t remember what exactly it was though. But it was deliberately introduced.
> (btw 1st thing I always do is `ln -s "Application Support" ~/Library/AppSupport` to get rid of that silly space)
>> I have to have XDG_DATA_DIRS set in my KDE 4 development setup if I want
>> to find all the mime types.
> That's curious, I never noticed any such thing …
Well, I need all these only for the OSX/CI system.
>> I guess the CMakeLists.txt files must somehow construct and install whatever
>> trees lie below GenericDataLocation or DataLocation (GenericDataLocation
>> value followed by
> Sh@@t, indeed, whatever changes we make to Qt code will have to be mirrored by the CMake system. Which in turn might help get things right with dbus c.s.?
Yes, that’s why I also have to be careful with what I change on the CI system,
like in case of bovo’s theme location , which removes this from the
darwin-mavericks platform configuration:
CMake and QSP have to be synchronised, that’s what was also underlined on K-F-D a couple
of times during this summer, i.e. every time when I tried to get help with my QSP patch.
Luckily Ian’s post on KDE-MAC finally brought movement again!!! :)
P.S.: I see already that building kconfigwidgets, kservice, kio, kinit, kdesignerplugin,
and kded already failed and I do expect more to follow due a good old friend,
namely their inability to locate
which needs some rework on my end! But I really wonder why this happens, as the
frameworks in question should be able to locate everything now natively since
they’re aware of the XDG_*_DIRS vars after all.
More information about the kde-mac