Theming, again

[Aaron J. Seigo]

On Monday, June 4, 2012 20:51:31 Ivan Cukic wrote:
> - non-stretch borders or center
>    is there any important theme really using this?

i think one or two themes are ... but we could just settle on or the other and 
say "that's how it is now"

> - mask
>    ok, this serves some purpose - defines the mask for blur and overlay
>    (see next item)
> 
> - overlay
>    introduced for a single purpose - to show circles in the Air theme.
> Later, to show rectangles. Now not used by the theme it was designed for at
> all. I do use it in one of mine, but I'm still for dropping it.

+1 .. overlay was a neat idea, but i agree that it could be removed with the 
following provisions:

* we document what we learned from the experiment
* if we bring it back, we do it better

> - applying colour scheme
>    introduced for Aya so that it can emulate the application style.

no, this is still often requested. it could be implemented in a better way (in 
fact, when we go all-singing-and-dancing-opengl-with-shaders, we can definitely 
do it better).

> - background as one element with borders on top
>    (this is one of my favourite features and will hurt anyone who
>    removes it :) )

:)
 
> So, IMO, some of these are consequences of wanting to do a lot of features
> without doing programmable theme engines. Now that QML will be in the
> background, most of them could be done in a different way.

agreed; there are other options open for us .. but i am still dead set against 
anything involving designers needing to include snippets of code. it must be a 
100% visual process, and it must use tools artists are familiar with as much 
as possible.

> We have issues that aren't a direct consequence of FSVG, but fixing them
> would make it a lot more complicated, and tailored to special cases.
> 
> - visually connecting the popups with the applets
>    example: http://kde-look.org/CONTENT/content-pre1/53086-1.png
>    or a 'triangle' pointing to the applet or anything else that people can
>    devise
>    (yeah, this is my main issue)

i don't see the connection, tbh :) educate me ...

> - differently presenting items (tasks for example) in panels that are
> vertical, horizontal, etc.

not sure this is related to themes?

> - (just so that Aaron has a reason to kill me) custom rotating animations on
> task hover and similar :)
> 
> - setting different coloured backgrounds for different applets

neither of these things will ever be supported for reasons that were beaten to 
death 2+ years ago now.

> > > The issue with the current usage of it (and we are all to blame for
> > > this one - it *is* a nice tool that covers a lot of use-cases) is that
> > > it exists as a first class citizen - if you just want a simple
> > > round-corner rectangle painted, you still need to use svgs. (iirc,
> > 
> > * where is that written?
> 
> What do you mean? It is not written that coders need to use FSVG, but if you
> are a theme maker, you can't just say "i want a simple rectangle for the
> background of an applet", you need to make a 9-element svg.

ah, you mean for artists.. yes, this is not efficient, and a matter of tooling 
rather than the implementation. coders don't write in assembler either 
anymore.

> > * what are the real performance issues with this? (as in: has anyone
> > measured? i did a bunch of measurement a couple years ago so that we got
> > to
> > the current acceptable point...)
> 
> The official issue *was* (don't know how relevant it still is - needs to be
> checked) that amarok started slower because of plasma theming.

i would definitely want to see #s. not only did amarok do all sorts of wild and 
interesting things with libplasma, theming performance improved considerably 
over time.

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20120604/d97bbb2f/attachment.sig>