Theming, again

[Marco Martin]

On Monday 04 June 2012, Ivan Čukić wrote:
> Hi all,
> 
> With qml-ifying plasma, we have the opportunity to completely break
> the current theming system and make something that would work. I'm

well, not really, since svg and framesvg are directly binded to qml (and quite 
heavily used, even outside of components) so current qml stuff already has a 
pretty heavy dependence on it, at least the api part of it (would be possible 
to maintain 100% compatibility of current qml code if the api of framesvgitem 
is kept even using a different backend).

> usually all for back-compatibility, but in this case I think we should
> start from scratch. We have already had discussions about why the
> current theming system is not sufficient, so I'm not going to repeat
> them.
> 
> With the plans [1] for QML themes, we'll get a proper theming for
> Plasma widgets, the thing that will remain is to do the same for
> applets, panels and similar.

desktop widgets will have (at least i hope) be painted with qstyle, for 
retrocompatibility, is still not really clear what are the plans for something 
different from qstyle, that post seems still deep in the investigative phase 
(Daker, any news/updates about that?)

as i said, my main concern is that framesvg is used a lot around in qml, so 
that would require again a new porting effort.

ignoring that for a moment, what i would like is:
* still workspace look different at least potentially from the app look, even 
if just a different default theme
* themes completely pixmap/svg//graphics based, no code involved, not even qml
* for sure nothing based on qstyle ;)

as capabilities, overall i like framesvg (way, way more powerful than 
BorderImage that i quite dislike), speaking of not retrocompatible changes..
there are things that revealed to be pretty painful, like having to have the 
borders actually splitted in different elements rather than split the rendered 
pixmap afterwards, having to design the thing from scratch i would make it 
behave in a radically different way.

main concern is mostly performance on scene-graph since it would have to be a 
QQuickPaintedItem, meaning resize the svg, paint it in software on a texture, 
and upload the new texture every time, but there could be no way around it, 
any way is chosen in the end.

Cheers,
Marco Martin