desktoptojson and kservice

[Aaron J. Seigo]

Hi ...

So, the next fun thing I’ve run into is desktoptojson. Currently in Sprinter 
I’m just hand writing the json files for the plugins. However, in its TODO file 
is this:

* Metadata
 * localization/i18n in plugin metadata (name, description)
    * license
    * author information (name, email)
    * icon

This is all information we currently have in .desktop files (along with the 
infrastructure and people using it to translate them ..) so it makes sense to 
stick to that and simply translate to json from them at build time. 

Which brought me to desktoptojson .. and several questions:

While there are shortcomings in QSettings for parsing random INI files, I don’t 
think any of these apply to the .desktop files we use. Would there be any 
objection / reason against dropping the use of KConfig in desktop and moving to 
QSettings, turning it into a Qt only application? 

Assuming a move to QSettings, could it then be moved out of the kservice 
repository, which is tier3, and into something more tier1? In a perfect world 
this would come with ecm, even, or something similarly build-tools related. 
Any suggestions there?

What are the plans for i18n in desktoptojson? It currently does not catch any 
translations in the .desktop file.

Do we really want json files that look like this:

{
    "Comment": "List and switch between desktop activities",
    "Icon": "preferences-activities",
    "Name": "Activities",
    "Type": "Service",
    "X-KDE-Library": "krunner_activities",
    "X-KDE-PluginInfo-Author": "Plasma Team",
    "X-KDE-PluginInfo-Email": "plasma-devel at kde.org",
    "X-KDE-PluginInfo-EnabledByDefault": true,
    "X-KDE-PluginInfo-License": "LGPL",
    "X-KDE-PluginInfo-Name": "org.kde.activities",
    "X-KDE-PluginInfo-Version": "1.0",
    "X-KDE-ServiceTypes": [
        "Plasma/Runner"
    ],
    "X-Plasma-AdvertiseSingleRunnerQueryMode": "true"
}

While easier for KPluginInfo perhaps (as it can just use the same keys when 
reading from .desktop files), this is imho really quite messy and makes it 
precarious to use for applications that may want to use KPluginInfo (or other 
tools) with json files with other data in them. Yes, we could continue to use 
“X-Foo-” prefixes .. but this is very ugly json. Litmus test: would anyone 
construct the above when told to come up with a json format to hold the above 
information if they didn’t start with those .desktop files?

What would be nicer imho is sth like:

{
    "org.kde.PluginInfo": {
        "Description" : {
            "c" {
                "Name": "Activities",
                "Comment": "List and switch between desktop activities",
            },
            "de": {
                "Name": "Aktivitäten",
                "Comment": "Aktivitäten anzeigen und zwischen ihnen 
umschalten"
            }
        },
        "Details": {
            "Author": "Plasma Team",
            "Email": "plasma-devel at kde.org",
            "EnabledByDefault": true,
            "License": "LGPL",
            "Name": "org.kde.activities", 
            "Version": "1.0",
            "Icon": "preferences-activities",
        },
        "ServiceTypes": [ "Plasma/Runner" ]
    },
    Sprinter: {
        "AdvertiseSingleRunnerQueryMode": "true"
    }
}

Note that this removes a few entries such as X-KDE-Library, which isn’t used i 
KPluginInfo at all now, and "Type": “Service”, which is now redundant. It also 
introduces translations (though that means a bit more overhead as they will be 
parsed at runtime and stored in memory as part of the QPluginLoader process), 
and keeps those separate from non-translated items (Description vs Details .. 
best names I could come up with on the spot, not necessarily the best ones 
possible). It wraps it all up in a “org.kde.PluginInfo” block so that it 
doesn’t interfere with other tools.

it would be easy to augment desktoptojson to take data from other files (INI or 
json) passed in on the command line to merge them into the final product.

thoughts?

-- 
Aaron J. Seigo