Review Request 124066: Recognize X-KDE-FormFactor as stringlist

[Sebastian Kügler]

> On June 17, 2015, 7:24 a.m., David Faure wrote:
> > I don't really have the overview anymore, but the kdelibs4 solution was fully extensible, a servicetype desktop file could define new keys and their type. It looks like desktopfileparser.cpp doesn't have the same flexibility, if each and every app needs to add their keys to the code :(
> 
> Alex Richardson wrote:
>     Possibly we should let desktopfileparser read a servicetype file? Was also suggested here: https://git.reviewboard.kde.org/r/121672/
> 
> Sebastian Kügler wrote:
>     So it has to look in standardpaths and somewhere in the buildpath for a service file, then use that to generate the json file? I guess the servicefile could be fairly simple, as it just has to note unknown key/type combinations. The KDE4-style service files do have that information, and as long as we don't have to parse that at runtime, we should be fine. On the other hand, we'll get build-time dependencies on these servicetype files, as it's now not good enough anymore to install them at some point, the resulting json information is going to differ then.

Observation: I'm looking into parsing the proper servicetype, and I think it could be quite straightforward, if we're OK with going over all servicetypes installed at. Would incur some cost, but it would mean that apps can -- yet again -- add their own non-bool, non-int and non-string keys.

But ... as to this patch, I'd still like to see it go in because the formfactor key makes sense for pretty much all services, plugins and application, so the usecase is not simply per app, but we want to limit the plugins and apps per formfactor (this would also allow us starting with a different commandline option on a different formfactor (by providing more than one desktop file), and it's IMO the most flexible solution we can provide). It also means, that it should probably be elevated to premier API, so a new getter for KPluginMetaData makes sense. I'll add that and will update this patch.

At the same time, I'll work on parsing the servicetypes from desktoptojson, that should work just fine, as long as servicetypes are available at compile time (would not cause regressions anyway, since we don't support it right now, so would be a mere addition).


- Sebastian


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81520
-----------------------------------------------------------


On June 11, 2015, 4:16 a.m., Sebastian Kügler wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/124066/
> -----------------------------------------------------------
> 
> (Updated June 11, 2015, 4:16 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> -------
> 
> This patch adds X-KDE-FormFactor to the keys recognized as stringlists.
> 
> We would like to see this to go in to allow us to filter plugins (KCMs for example) by form factor, so we only display UI plugins that are suitable for a given target device.
> 
> The idea is that plugins indicate which form factor (for example media center, tablet, desktop, etc...) they're suitable for, and the "host application" filters based on these.
> 
> If this approach is deemed valid, I'd be happy to add convenience API to KPluginMetaData, i.e. QStringList KPluginMetaData::formFactor(). This patch would be the minimal implementation we'd need.
> 
> The naming of the key is of course open to better suggestions.
> 
> 
> Diffs
> -----
> 
>   autotests/data/fakeplugin.desktop 95152f6 
>   autotests/kpluginmetadatatest.cpp 231ac36 
>   src/lib/plugin/desktopfileparser.cpp b19da6b 
> 
> Diff: https://git.reviewboard.kde.org/r/124066/diff/
> 
> 
> Testing
> -------
> 
> added autotest, also implemented using this in the Plasma Active settings app as proof-of-concept, works like a charm.
> 
> 
> Thanks,
> 
> Sebastian Kügler
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20150617/decce482/attachment-0001.html>