c++ plugins with Frameworks 5

[Aaron J. Seigo]

hello,

over the weekend i wrote up a small tool that does what is needed for 
libsprinter, which is a Qt5 library (no frameworks deps), to harvest 
translations from .desktop files into .json files for inclusion in its plugins.

one decision i made while writing this was that .desktop files are not of 
interest to libsprinter: they are there only to collect translations. as such, 
no .desktop files are actually installed, and all information is kept in the 
json that gets compiled into the plugin itself.

it uses a block in the json metadata that looks like this for application-
specific information:

    "Sprinter": {
        "GeneratesDefaultMatches": true,
        "MatchSources": [
            "FromDesktopShell"
        ],
        "MatchTypes": [
            "WindowType",
            "DesktopType"
        ]
    }

and the plugin info is kept in a separate PluginInfo block, which replaces 
what was in the .desktop file. translations added to the .desktop files are 
merged into the json files with a small tool that can be run by the build 
system.

pros: the data is only installed in one place; it is easy for applications to 
extend the json
cons: there is both a .json and a .desktop file in the source repository


looking at how Frameworks 5 based applications with plugins are handling this, 
a slightly different approach is being taken: the .desktop files are still being 
installed and ksycoca is being queried for them. at the same time, this data 
is duplicated in the plugin’s json data as well so that can be used at runtime 
to query information about a specific plugin.

pros: easy for migration
cons: the data is duplicated in two places on disk with no clear sign of which 
is the preferred means of accessing the data; application extensions to the 
json data is not well supported (in the above json snippet, all three entries 
would become strings which would need further parsing once retrieved from the 
plugin’s metaData())

really, this is a minimal-effort adjustment to accommodate the use of json in 
plugins without altering anything else. 

while this makes sense for applications in transition from 4.x to 5.x, is this 
how new applications are also expected to be written?

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 :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140303/dc8eecb2/attachment.sig>