Theming, again

[Daker Fernandes Pinheiro]

Hi,

2012/6/4 Marco Martin <notmart at gmail.com>

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

Maintaining compatibility with SVG wouldn't be hard.
It would be needed a QML Style that could handle SVGs as Themes.


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

Exactly, the QStyle painting will be there for retro compatibility and
implementing
new styles with QML are possible, but the goal is opening doors for Styles
written in QML or C++ QtQuick.


> different from qstyle, that post seems still deep in the investigative
> phase
> (Daker, any news/updates about that?)
>

It's important to notice that currently it's a separated project from Qt
Desktop Components.
Our intention is to join both efforts and this will be under discussion at
QtCS.
I hope that something good comes out from it.


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

In the proposed architecture [2], the porting effort wouldn't be much
painful, at least for the Plasma Components.
Please let me know what else we could make themable.
It would require removing the interaction code from the Plasma Components
and transforming it into a Style.
Obviously, this simplification of the Plasma Components would add these
desktop components dependecy  on Plasma.


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

This would be perfectly covered. We are also carrying on with the project
what we call CustomStyles.
This styles set is a helper for creating styles using pixmap/svg/graphics.

* for sure nothing based on qstyle ;)


Surely not. :-)


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


That's true.
But enabling themes/styles in QML can makes them free from QQPI for
new styles that can be written.


>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>

[2] http://codecereal.blogspot.com.br/2012/04/qml-themingstyling.html

Br,

Daker Fernandes Pinheiro
http://codecereal.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120604/20a01510/attachment-0001.html>