Review Request 122706: A KCModule base for QML based KCMs

[Ben Cooksley]

> 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
> 
>

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