Re: desktoptojson and kservice
On Friday, February 21, 2014 15:45:25 Sebastian Kügler wrote: > Including the translations would mean that all translations have to be there > at compile-time, which would mean that runtime changes to translations > aren't picked up. ... are there such things as “runtime changes to translations”? yes, they currently are in non-compiled files (.desktop INI-style files), but do those get updated on people’s systems without the plugin they relate to also being part of the update? -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: desktoptojson and kservice
On Friday, February 21, 2014 13:51:47 Aaron J. Seigo wrote: > Aaron J. SeigoOn Friday, February 21, 2014 13:41:29 wrote: > > What are the plans for i18n in desktoptojson? It currently does not catch > > any translations in the .desktop file. > > actually, i think it might be worse than “does not catch any translations”: > if it does what i suspect it does, it takes the translated versions of the > strings of whatever locale the user currently has set. so if someone using > german as their language, whenever they run desktoptojson they’ll get > german strings rather than the default english ones. > > has anyone tested this with non-’c’ locales? Including the translations would mean that all translations have to be there at compile-time, which would mean that runtime changes to translations aren't picked up. It does indeed mean that the plugin info coming from the json info in these plugins is not translated, which is a problem indeed. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: desktoptojson and kservice
On Friday, February 21, 2014 13:57:07 Kevin Krammer wrote: > If we want to be able to parse .desktop files without KConfig, we need a > desktop file parser. valuable to know, indeed. thanks for sharing your experience, saves me some effort. > The Razor-Qt and LxQt people might have one already. yeah, i was wondering the same thing ... will take a look around. a long while ago i had found such a class on the Internet. perhaps qt3 days? hm.. google, here i come. -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: desktoptojson and kservice
On Friday, 2014-02-21, 13:41:29, Aaron J. Seigo wrote: > 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? One limitation we hit recently in Akonadi server is that QSettings can not correclty deal with comma in strings. Basically it interprets any value with a comma in it as a list instead of a string. This generated a problem in Akonadi when Akonadi Control, which is "Qt-only" used QSettings to parse .desktop files of Akonadi agents. Translators found out that if they had comma in the translation, then these strings would not show up in user interfaces anymore. The Akonadi maintainer worked around it by joining QStringList on fields that are expected to be strings, but of course that is not always the same as the original string. If we want to be able to parse .desktop files without KConfig, we need a desktop file parser. The Razor-Qt and LxQt people might have one already. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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
Re: desktoptojson and kservice
Aaron J. SeigoOn Friday, February 21, 2014 13:41:29 wrote: > What are the plans for i18n in desktoptojson? It currently does not catch > any translations in the .desktop file. actually, i think it might be worse than “does not catch any translations”: if it does what i suspect it does, it takes the translated versions of the strings of whatever locale the user currently has set. so if someone using german as their language, whenever they run desktoptojson they’ll get german strings rather than the default english ones. has anyone tested this with non-’c’ locales? -- Aaron J. Seigo ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
desktoptojson and kservice
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
