c++ plugins with Frameworks 5

[David Faure]

On Monday 03 March 2014 12:28:07 Aaron J. Seigo wrote:
> do we want .desktop files as well as generated .json?
> 
> if so, for applications that wish to put additional data in the json files,
> is  it expected that they continue to do this by adding more “X-Foo”
> entries to the [Desktop Entry] group in their .desktop files? (as opposed
> to providing actual json)
> 
> whatever the decision is, more work will be needed: 
> 
> * desktoptjson does not support translations currently (made difficult by
> use of  KConfig) and does not support application extensions to the json
> very well, both of which need attention.
> * in the json-only approach is adopted, KPluginInfo and possibly even
> ksycoca  would need adjusting (the latter to preserve the ability to do
> KService-based queries)
> 
> i’m willing and able to do the latter if the decision is made to support
> json- only. (i’m not willing to do that work if it isn’t, as i prefer not
> to waste my time :)

I am completely in favour of dropping .desktop files so that we can drop 
ksycoca, which is my number one target for being shot down.

The plan for app desktop files (as per my last freedesktop-summit report) is a 
mmap'able binary cache generated at install time with a cross-desktop tool.

This leaves no room for kde-specific plugins (Type=Service desktop files),
so either we make our own binary cache for these, or... we drop desktop files 
altogether.

But then the question is indeed, how will we make queries (other than "give me 
all the plugins of type foo" which can and should be done by organizing them 
in a subdir "foo").

What I don't know is how much do we need support for queries that filter this 
further, and whether just reading the json from all the plugins of type "foo" 
is good enough.

All this being said, please ensure you get feedback from Sebas too, who worked 
a lot on this stuff :-)

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