> 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. > > Sebastian Kügler wrote: > 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).
Ah OK I didn't know it would make sense for all services, plugins and applications. +1 then. - David ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124066/#review81520 ----------------------------------------------------------- On June 17, 2015, 11 p.m., Sebastian Kügler wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/124066/ > ----------------------------------------------------------- > > (Updated June 17, 2015, 11 p.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 > src/lib/plugin/kpluginmetadata.h 4572d36 > src/lib/plugin/kpluginmetadata.cpp eaaf0b9 > > 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
