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