Re: Review Request 122706: A KCModule base for QML based KCMs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review78707 --- This is now obsoleted? - David Edmundson 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
Re: Review Request 122706: A KCModule base for QML based KCMs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76873 --- +1 - David Edmundson 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
Re: Review Request 122706: A KCModule base for QML based KCMs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76597 --- src/CMakeLists.txt https://git.reviewboard.kde.org/r/122706/#comment52767 You can add the comments there as well, no? Somebody took his time to write the rest... Also, would it maybe make sense to have a different library in KConfigWidgets for this? It seems quite disjoint from the rest... - Aleix Pol Gonzalez On Feb. 24, 2015, 11:39 a.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/ --- (Updated Feb. 24, 2015, 11:39 a.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
Re: Review Request 122706: A KCModule base for QML based KCMs
On Feb. 25, 2015, 12:07 p.m., Marco Martin wrote: Also, would it maybe make sense to have a different library in KConfigWidgets for this? It seems quite disjoint from the rest... it's a base kcmodule, so i don't think so - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76597 --- On Feb. 24, 2015, 10:39 a.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/ --- (Updated Feb. 24, 2015, 10:39 a.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
Re: Review Request 122706: A KCModule base for QML based KCMs
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
Re: Review Request 122706: A KCModule base for QML based KCMs
--- 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 (updated) - 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
Re: Review Request 122706: A KCModule base for QML based KCMs
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. 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. - Sebastian --- 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
Re: Review Request 122706: A KCModule base for QML based KCMs
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
Re: Review Request 122706: A KCModule base for QML based KCMs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76528 --- CMakeLists.txt https://git.reviewboard.kde.org/r/122706/#comment52695 this one also seems unused? - Hrvoje Senjan On Feb. 24, 2015, 11:24 a.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/ --- (Updated Feb. 24, 2015, 11:24 a.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
Re: Review Request 122706: A KCModule base for QML based KCMs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/#review76526 --- CMakeLists.txt https://git.reviewboard.kde.org/r/122706/#comment52689 why KF5Plasma? As far as I can see it doesn't use anything of plasma. Might it be that you meant KPackage? src/kcmoduleqml.cpp https://git.reviewboard.kde.org/r/122706/#comment52692 nitpick: 0 - Q_NULLPTR src/kcmoduleqml.cpp https://git.reviewboard.kde.org/r/122706/#comment52691 will that work on Wayland? src/kcmoduleqml.cpp https://git.reviewboard.kde.org/r/122706/#comment52690 why plasma? - Martin Gräßlin On Feb. 24, 2015, 10:29 a.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122706/ --- (Updated Feb. 24, 2015, 10:29 a.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
