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

[Jeremy Whiting]

David,

Some thoughts on this.

On Sun, Feb 1, 2015 at 7:20 AM, David Faure <faure at kde.org> wrote:

> On Saturday 31 January 2015 19:28:21 Jeremy Whiting wrote:
> >  Another question that
> > might help clarify this, do Gnome/Unity, other linux desktop environments
> > use the cache kbuildsycoca creates when building their menus or is it
> > strictly used by plasma (or rather kickoff/kicker which is part of
> plasma)
> > itself?
>
> Neither statement is correct.
>
> Gnome doesn't use ksycoca.
> Plasma menus use ksycoca.
> BUT also any KF5-based app needs ksycoca, so that e.g. when you click on a
> link to an image in, say, kmail, it knows how to find an image viewer and
> start it.
>
> kbuildsycoca generates ksycoca which is used by any app that needs to look
> up
> "which application can handle this mimetype" as well as "which
> part/component/plugin can provide this type of service (and handle this
> mimetype)".
>

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.
Couldn't kf5/qt5 based applications on OSX just use that same mechanism for
opening files in other applications? 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)?

Basically, the big question is does ksycoca need  to scan all the .desktop
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).

>
> The latter is slowly migrating to a json-based plugin discovery in KF5, but
> for now many things still work like in kdelibs4, with desktop files
> describing
> parts/components/plugins, therefore ksycoca is needed.
>

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.

>
> I have long term plans to be able to do the application-lookup stuff
> without
> ksycoca, but these plans are progressing very slowly (one freedesktop
> meeting
> per year...).
>
> > Are they required for kparts to work, or for KService/KServiceTypeTrader
> to
> > work?
>
> The above answers this, for they == kbuildsycoca+kded.
> The part of "they" which points to kdeinit+klauncher is mostly unrelated.
> They
> are not needed for looking up stuff. They are optionally used for starting
> up
> stuff (at least a bit more "optionally" than in kdelibs4). They are however
> needed to start kioslaves - because of the feature to be able to put a
> slave
> on hold (after finding out the mimetype) and give it to another app.
> Can happen in the kmail->browser example, to avoid posting something twice.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20150204/b67ada3a/attachment-0001.html>