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

[David Faure]

On Wednesday 04 February 2015 09:23:58 Jeremy Whiting wrote:
> I can see the use case for kf5/qt5 based applications wanting to know what
> part/component/plugin can provide a service, but I'm not sure why they
> would need ksycoca for launching applications. OSX has LaunchServices
> (which I read about yesterday because I was curious how it worked) to
> decide which application to open when "open foo" is used at a terminal, or
> a file of a given mime type or a given extension is opened in Finder.

Can it also return the list of associated applications, rather than just 
"execute the preferred one"?

This is needed for other use cases like "right click on a file in dolphin, 
then go to the Open With submenu, it shows the list of associated apps".

If that's the case, then it means we could write a platform-independent API 
for "give me the apps for this mimetype" and implement it differently on 
different platforms (rather than using ksycoca and desktop files everywhere).
This should ideally go into Qt though, which becomes possible once the binary-
cache-at-install-time (like for mimetypes) replaces the ksycoca solution, 
which is a long-term project of mine....

> files in $PREFIX/share/applications for kservice/kparts to work or is that
> only needed for opening files/urls in external applications? And if the
> latter can't we use the platform's own file/url handling (I would hope Qt's
> QDesktopServices::openUrl would do the "right thing" on osx for us here,
> but haven't tested it yet).

openUrl works but doesn't solve the whole issue.

> Ah, I guess that answers my question about kparts/plugins/components, so we
> need to get kbuildsycoca5 on osx to search in $PREFIX/share/applications
> through the .desktop files then I guess? Or does it only need to search in
> $PREFIX/share/kservices5 as that appears to be where kparts at least have
> their .desktop files.

See above. In general, do a lxr search on KMimeTypeTrader, skip the ones that 
have a servicetype set (such as KParts/ReadOnlyPart) (the default servicetype 
is "Application"), and you'll be left with all the uses that are looking for 
applications, such as:

konqfactory.cpp:214:        *appServiceOffers = KMimeTypeTrader::self()-
>query( serviceType, "Application",

I assume these are all about either
- finding the preferred app, or
- listing all associated apps for "open with" type menus
but tell me if you find anything else.

Can also be about keditfiletype (system settings -> file associations), but if 
you're happy not to have that on Mac, and you have a native solution for the 
above two points, then yeah, you could do without desktop files.... except 
that you'll need to register the KDE apps to the mac natively, as discussed in 
another subthread, AFAICS.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5