[KDE/Mac] Cross-platform with kdeinit5, klauncher5, kded5 and friends

Ian Wadham iandw.au at gmail.com
Sat Jan 31 04:39:07 UTC 2015


On 31/01/2015, at 1:24 PM, Jeremy Whiting wrote:
> On Fri, Jan 30, 2015 at 7:04 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> On 31/01/2015, at 10:34 AM, Jeremy Whiting wrote:
> Ian wrote:
> As far as I can tell, Apple OS X does not use the main *.desktop files when launching
> applications (I mean files like ksudoku.desktop).  There are also *.desktop files used,
> for example, by games to record details of graphics themes.  But the ones that really
> matter, from the point of view of not breaking KDE4/KF5 applications, are those used
> to locate plugins, KParts and services (I hope I have used the right terms).  When KBS
> finds those *.desktop files, the apps that use them are no longer broken on Apple OS X.
> 
> Right, a quick find in my kdesrc-build prefix (/usr/local/share) for .desktop files shows these subfolders:
>  - applications
>  - bomber/themes
>  - carddecks/*
>  - kf5/locale/countries/*/
>  - kf5/locale/currency/
>  - kmahjongg/layouts/
>  - kservices5/
>  - kservices5/cantor/
>  - kservicetypes5/
>  - ktuberling/pics/
>  - kxmlgui5/parley/themes/
>  - locale/en_US/kf5_entry.desktop <-- this one is just a .desktop of translated language names, in every translated language. We used to use this in kanagram/khangman, but with Qt 5 we simply use QLocale instead
>  - picmi/themes
>  - plasma/desktoptheme/*/ <-- no idea what these are for, we most definitely don't need them though imo. Seems like a workspace only runtime requirement.
> 
> Of those I can see each application needing it's own .destop files read, but not by kbuildsycoca5 I don't think, since it's looking in ApplicationsLocation and these aren't under there even on linux. I think there's some other mechanism that's helping find those at runtime iirc. Parley for instance which uses a copy (shame on parley I know) of kgtheme uses QStandardPaths::locateAll in GenericDataLocation/parley/themes to find .desktop files and read them. I guess the original KGTheme probably does similarly.

Yes, KgTheme does.  Some apps look up subsidiary *.desktop files themselves (e.g.
KMahjongg's layouts), using KStandardDirs --- or QSP in future.

> As for KParts and services I think most of those come from either kservices5, kservicetypes5. I'm not sure if those sets of data are cached by kbuildsycoca5 or not, but they aren't by the code path that's taking a while on osx currently (VFolder::loadApplications).

I am pretty sure they should be.  Try running an app that uses one.  If they are not in
the cache, I think the app will fail when it tries to access the KPart or service.

> For example filelight which has a kpart has installed /usr/local/share/kservices5/filelightpart.desktop here. As for services I think those are all defined as dbus services in $PREFIX/share/dbus/services/*.service

Some applications have their own plugins.  Until I ran kbuildsycoca4 one day, a
year or two ago, those apps were broken.  For example, Kompare would bring up
its initial dialog, but not its side-by-side comparison window, and Palapeli would
let you solve jigsaw puzzles, but would not create new ones.  In KDE 4, I am
thinking of these files in $KDEDIR for Palapeli (there is a choice of 3 slicers):

    services/palapeli_goldbergslicer.desktop
    services/palapeli_jigsawslicer.desktop
    services/palapeli_rectslicer.desktop

When one of these is found, the right library can be found and loaded into the
app.  AFAIK kbuildsycoca4 puts their locations in a cache file.  I do not know
what looks up the locations in that cache when a plugin is needed.

Cheers, Ian W.



More information about the kde-mac mailing list