> 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? > > Marco Martin wrote: > 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. > > Sebastian Kügler wrote: > Makes sense. I think we can combine the two approaches. > > * New-style QML "KCMs" do not link KCModule directly, but rather use the > imports you describe. > * A special-sauce KCM does the necessary bits to load these new-style > KCMs (pretty much what this patch does, really) > > That way, we allow legacy-free new-style, but make it compatible with > everything old-style, QWidget-based KCMs, systemsettings, kcmshell, etc. > > A new "systemsettings-qml" would have to be special-cased in order to > also load KCModule/QWidget-based modules, but I don't think there's any way > around that anyway.
The architecture of System Settings should allow it to host native QML KCMs without having to use the KCModule class, assuming the appropriate changes are made. - Ben ----------------------------------------------------------- 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
