[RFC] Port PlasmaComponents to use QtQuick Controls where applicable

[Marco Martin]

On Monday 19 August 2013, David Edmundson wrote:
> After discussions with a few people, I decided for an experiment to port
> PlasmaComponents Button to use QtQuickControls [1] internally but use the
> styles API [2] to make it look like the original PlasmaComponents button.
> 
> This is pushed in the plasma-frameworks branch davidedmundson/controls

I'm still seeing advantages and disadvantages, but i like the idea.

If this will be how we proceed, it shouldn't be done inline, but as a 
standalone style together the others.

so installed in qml/QtQuick/Controls/Styles/Plasma
(seems so far has to be there, even tough should be possible to put it 
somewhere else too, that would be better, maybe messing a bit with import 
paths)
at the moment seems to have to be either setting an environment variable

or (should be used for now i think)

style: Qt.createComponent("Plasma/ButtonStyle.qml", button)
instead of the default
style: Qt.createComponent(Settings.style + "/ButtonStyle.qml", button)

qquickcontrolsettings.cpp should be modified to be allowed to have a different 
style set per qqmlengine.
So using always qquickcontrols would give plasma style on the desktop/panel 
views, but the desktop style on the configuration windows (on plasma desktop, 
but plasma style in plasma active)

in general, from what i tried of qtcontrols there will be still a lot, a lot 
of work to be done in them to be remotely ready (probably a bit less work to 
be ready for plasma since we always wanted a limited set anyways)

for being able to do a decent desktop application (or even just the settings 
dialogs) some things are still needed, in part feature missing, in part making 
it play well with oxygen (and oxygen play well with them) since it's a qstyle 
infinitely more complicated than the very simple ones qt5 is shipped with.

> Advantages:
>  - considerably simpler code. We don't have to do our own mousearea and key
> handling. It's all done for us. I reduced Button.qml to about 1/2 the
> original size
>  - consistent API with the configuration controls and other QML users
>  - more code sharing is better
>  - we get some features for "free". For buttons we get action support,
> exclusiveGroups, tooltips

and more important, that qualifies both as advantage and disadvantage:
- qtquickcontrols will be beaten to their limit, hopefully getting implemented 
upstream what is still missing

> Downsides:
>  - Source breakage
> Although the API is very very similar, there are some differences.
> For just button; icon -> iconName/iconSource, no font property
> We /could/ bodge it with alias's. For other components this may be more
> difficult

what is really necessary should be done upstream (in the case of font, 
probably is not really necessary to have it, or at least not until there is a 
very valid use case)

for the icon, anyways the label component should be reimplemented anyways, for 
the color palette of the label, and for the icon itself, that should still 
prefer monochrome ones if icon name is defined (so icon in this case should 
again support both names and icons)

the biggest api roadblock i seen so far is the rename of some components:
PageStack -> StackView
ScrollArea -> ScrollView    (both with minimum changes in the api)
pretty nasty is TabBar, that is completely different with no relation 
whatsoever with the one we had (that i kinda prefer because the tabbar and the 
tab view are two separate entities)

>  - More work.
> As a rough guide I ported Button in about 1 hour. It's not a perfect 1-1
> port, but it's 90% there.
> 

yeah, not sure if this is underestimated

> I think given the current API changes it makes sense to use this
> opportunity to make this change. I believe we will get better more stable
> code for it. I can do most the changes.
> 
> Thoughts?

not 100% sold yet due the pain that will cause, but yes, in the future i would 
like to have plasma themed qtcontrols with our controls being purely 
extensions, controls that aren't available otherwise

-- 
Marco Martin