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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
