> On Feb. 24, 2015, 10:59 a.m., David Edmundson wrote: > > src/kcmoduleqml.h, line 36 > > <https://git.reviewboard.kde.org/r/122706/diff/3/?file=351295#file351295line36> > > > > When we do make a QML only system settings we're not going to want to > > use KCMModule at all, even if it's not shown? > > > > I imagine we'll end up writing a small QObject shim that copies the API. > > > > I'd just leave this until we find we need it, otherwise we're > > committing to a slightly weird API prematurely. > > Marco Martin wrote: > I can move it out for now, but i don't think is realistic to expect to > port everything away from kcmmodule overnight. porting all to this will be > hard enough already, reporting a second time i think is really a framework6 > thing. > If there will exist a qml based systemsettings, it will have to be able > to load things all the way in the transition spectrum: old qwidget ones and > those, which can ignore the qwidget part. It's clearly transitional but i > don't think there is a way to realistically have qobject only ones before > there is something working in place?
Thinking about it, one way that and almost legacyless way could be done is: having in a separate library, tier2 a qobject based thing that has an api similar to kcmodule, and doing the qml kcms directly in that. then this class goes in pretty similar, except the plugins wouldn't subclass it, but would be used directly to load one of those qobject only thinghies. the disadvantage would be that systemsettings, kcmshell (and pretty much any app config dialog that loads kcms) would have to directly special case for this, so the transition would be more painful. - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76534 ----------------------------------------------------------- On Feb. 25, 2015, 5:40 p.m., Marco Martin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122706/ > ----------------------------------------------------------- > > (Updated Feb. 25, 2015, 5:40 p.m.) > > > Review request for KDE Frameworks. > > > Repository: kconfigwidgets > > > Description > ------- > > this adds a new class called KCModuleQml > it loads a KPackage with the same plugin name as the kcm, then loads its > mainscript qml file from it and puts it in a QQuickView used as main widget > of the KCM. > > It supports two ways of loading the qml: > one is in the showevent of the KCM qwidget, this is compatible with current > Systemsettings and kcmshell. > the other way is with the mainUi accessor/qproperty. This will make possible > for a pure QML version of systemsettings (accessing directly mainUi without > showing qwidgets) > > > Diffs > ----- > > CMakeLists.txt f3aaf18 > src/CMakeLists.txt 10862c6 > src/kcmoduleqml.h PRE-CREATION > src/kcmoduleqml.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/122706/diff/ > > > Testing > ------- > > > Thanks, > > Marco Martin > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
