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-de...@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-de...@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 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel