Theming, again

[Ivan Čukić]

Not thinking anymore this has a purpose since, as Marco said, there
are more important things to do. And the API doesn't need to change in
order for us to later change the FSVG.

But, here are the answers... for the record, and as a thought experiment :)

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

So, the texture Marco mentioned. For me, a texture is in background,
not an overlay. So, kinda misused most of the time.

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

I know it is. Just listed it as an example of a feature that was
invented to do something real in a hacky way that our way of theming
wasn't really meant to do :)

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

With this I agree. Nevertheless, that shouldn't mean (like it is now)
that coders who do design well (two of them come to mind that are
involved in this thread - btw, this is the reason I started it -
http://www.notmart.org/index.php/Graphics/A_UX_manifesto,_universe_and_eve
:D )

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

FrameSVG is a rectangle. Popup with a triangle is not :D (we talked
about this some time ago - is it possible to make something like this
by adding more power into FSVG, and we abandoned the idea since it
would look quite ugly or underpowered)

Maybe I could draw it at T6.

>
>> - differently presenting items (tasks for example) in panels that are
>> vertical, horizontal, etc.
>
> not sure this is related to themes?

Imagine a theme that tries to make a 3D dock (like some proprietary
OSs do, a few people try this, and I was even sponsored to do it at
one time... I felt dirty). So, the tasks background ought to be 3D as
well (http://tipsfromgeek.com/wp-content/uploads/2010/03/cairo-dock.jpg).
For the top panel, this 3D perspective would be *ugly*. So you want
something different - create a different panel bg for the top...
check... create a task bg that fits it - you can't.

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

This is not about different backgrounds for different widgets (nor
client-side window decorations :) ) - it is about making a
consistently-looking theme that doesn't show all widgets as equals.
Currently, we have translucent folder views, post-it looking notes as
a special cases which don't break the consistency.

For example - changing the border that is near to the edge of the
screen, changing the 3d perspective based on the position of the
widget to achieve a real 3D effect, or a real shadow etc.

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

Agreed.

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

+1



-- 
Cheerio,
Ivan

--
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun