Plasma Themes (for all plasma devs)

[Aaron J. Seigo]

On Saturday 19 April 2008, Ivan Čukić wrote:
> > an "API review" of these would indeed be nice. not critical, per say, but
> > would a decent use of time imho.
>
> It's a bit late for this since it would break existing themes...

there's probably no reason we can't do multiple versions of themes.

> > > And still, there is so much that can not be done with this ever-growing
> > > implementation of themes.
> >
> > what in particular are you considering?
>
>  * For example, consider the Silicon and Shelf themes. If the widgets are
> rotated, those themes just look weird. The reflections in Silicon and the
> shelves in Shelf should always be down. It can not be done now.

solution?

(perhaps rotate the background if a flag is set?)

>  * there is no possibility to create a real reflection.

"real reflection"... of? the widget on the background, for instance? if so, 
that can be done in code and has, tbh, zero to do with themes.

just as with shadows, perhaps we're getting a bit confused as to what belongs 
where. not everything needs to be in the svg.

>  * blurring the background below the widget (brushed glass effect)

see above. even if this *was* in the svg, for rather obvious painting reasons 
it wouldn't work. hell, we can't even do this properly in C++ right now due 
to limitations in QGraphicsView.

>  * the shelves can not have a common vanishing point and look weird

that's an interesting one. would have to think on how to solve it, though i'm 
tempted to say "neat, but not worth screwing over the theming system".

more important than being to replicate every visual effect possible is making 
it possible for artists to get involved without a coder. we could list an 
insane number of graphical effects that would require code support to do.

>  * the background glossiness (look at the theme named Blue) stretches with
> the background and looks ugly. No way to make it fixed size. (to combine
> stretched, tiled and fixed elements in one background)

interesting one, should be solvable.

>  * I like the panels to be dark when the desktop is shown, but I would like
> them to become lighter when there is a window maximized - to fit the
> surroundings. (making the room look bigger by placing mirrors on walls
> effect) * themes could adapt to the wallpaper (even to adapt widget
> background with regard to color of the wallpaper that is below the widget)

see above comment on "insane number of graphical effects"

these are things that would get used by a vanishingly small number of people, 
provide little real value while making everything more complex and less 
approachable for those looking to customize things. it's a net loss.

>  * and probably the most requested thing, the plasma widgets can not look
> like the window widgets (i have no problem with this, but others ... khm,
> khm Lubos khm... khm... seem to ;) )

i think the term is "irrelevant". we use regular QStyle stuff for, well, 
regular QStyle widgets. last time i checked, QStyle didn't do desktop panels 
and kwin's window decs weren't applicable to desktop widgets either.

> > i'm completely against going for anything that requires writing code
>
> I know :) I am against it too, but it is the only way that comes to my
> mind. 

redefine the problem. coding is *not* an option. period. eol. so fit the 
problem into the allowed solution space.

> We could have a couple default engines so that for most cases people 
> do not need to code anything - for example, one engine could implement the
> current plasma's behaviour etc.

no. here's why:

this is something that can be added at any point in time. we do not need to do 
it now.

if we do it now, some people will take advantage of this without actually 
thinking hard about what real themability is needed and svg based themes will 
undoubtedly suffer.

the coded results stand a high chance of exuding visual crappyness.

it's one more distraction.

KISS.

> It would allow us to break back-compatibility in a sense - when we decide
> that we should rethink the SVG elements for example.

i don't see this as a problem even with what we have.

> > because that locks out virtually all designers. if we're edging towards
> > ever greater complexity so that we will find ourselves in a very awkward
> > situation down the line, then the artists need to stop themselves, sit
> > down and FORCE themselves to answer hard questions with good answers.
>
> I agree with you on this one, but it is hard to imagine what will people
> try to do. For example, the mentioned Shelf theme - if I haven't seen the
> theme, the idea to have shelves would never occur to me... and it's cool.

well, shelf is borrowed from the latest macos x. so it's not all that 
unobvious if you've seen it ;) that said, there's a ballance to be struck 
between "making all things possible" and "making something that is 
realistic". remember the target profile of "artists should be able to theme 
things".

*if* we provide something more interesting than plain svg, it must integrate 
with tools like inkscape directly, provide 100% gui driven creation and *no 
source code* must be visible to the creator.

i really don't think anything in between is worth chasing.

meanwhile, we haven't actually done a review of the "API" in the svg themes ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20080419/821f0209/attachment.pgp