[KDE/Mac] Cross-platform with kdeinit5, klauncher5, kded5 and friends
René J.V. Bertin
rjvbertin at gmail.com
Wed Feb 4 16:57:02 UTC 2015
On Wednesday February 04 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.
That depends on how the application is launched, right? If directly, I presume the path is used, but if it's "launch the application that can handle this or that kind of file", you need a lookup service to find the application name before you can launch it.
> Couldn't kf5/qt5 based applications on OSX just use that same mechanism for
> opening files in other applications?
Yes, that could be done, but at the very least that means that someone has to code the required metadata and store that in the application Info.plist dictionary. You've probably seen that with LaunchServices, it's the application that tells the system what document types it can handle (as well as what kind of documents it creates).
There's 1 big difference here: I know of no way to provide that information to the system before the application is present (other than using a stub application).
Also, it's not at all certain that that metadata will be read and included if an application is installed through some commandline process rather than by dragging its icon into a folder with the Finder, or using an installer. There may be a way to trigger the Info.plist parsing during a Unix-style install, but I don't know how ATM.
> I.e. why wouldn't kmail on OS X use
> whatever the user has set as their default browser when opening http urls
> and whatever the user has chosen as their default image viewer when opening
> image file attachments (if they aren't using the embedded image viewer or
> kpart I guess)?
I have configured a number of things to be handled by "open", exactly because of that ;)
> 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).
IIRC, it does.
R.
More information about the kde-mac
mailing list