plasma, panels, colours

[Aaron J. Seigo]

hi all...

it was mentioned on irc that the new taskbar styling made it difficult to see 
the active window. but when i looked at the svg, the different was pretty 
apparent ... it was just hard to see o the black background of the panel.

so i quickly editted panel-background.svg, tweaked the colours file and got 
this:

	http://plasma.kde.org/media/light_coloured_panel.png

well, almost ..

i also had to go in and tweak the colours that the tasks widget was using for 
the text, since i had to change the other text usage to something dark.

(and ok, the choice of colour in the panel there isn't great, but you get the 
idea)

it's really a lot more appealing with a non-black background. it could still 
even be a dark colour, but i really don't know how many distros are going to 
keep with the default theme when the default is, well, rather bleak.

i was hoping of putting this off until 4.3, but i'm increasingly thinking that 
waiting is not only unnecessary but also problematic.

it's unnecessary to wait because it really means just changing the background 
svg's. that means it' spossible to do with fairly small amounts of artwork 
effort. everything else looks really nice on a light background: the new tasks, 
the new system tray, the panel cashew, etc..

but more drastically, waiting may be problematic because i had to make that 
text colour change.

and more importantly ... it still isn't perfect.

i'm wondering if we might not need a different way to define and retrieve 
colours.

i went with KColorScheme because it was part of kdelibs. but the semantics of 
it aren't quite right for plasma, i think, and we're going to continue mapping 
more and more plasma contexts to KColorScheme colours, and that's really where 
it breaks down hard.

the taskbar may want light text colours; the pager may want dark text colours, 
but only when it's using NoBackground; when it's on a StandardBackground, 
perhaps it needs light colours. etc. ...

i haven't really come up with a firm solution yet, but it's something we need 
to think about because it may well impact the API of Plasma::Theme, which 
means it needs to be done before 4.2.0 is out if we want to do it at all.

i'm leaning towards coming up with a list of all the semnatic contexts we can 
identify, find some way to tie the applet context into it and then mate all 
that to classes in libplasma.

one possibility is a Plasma::Colors class which cooperates with Plasma::Theme 
in the background and takes a Plasma::Applet. it could take care of all config 
caching as well as semantic<->config value matching necessary.

now, i'm not sure i'm the best one to come up with such a list of colour 
contexts. mostly because, you know, i'm not an artist =P but i'm willing to 
write the code once we agree on a solution, have a list of colour contexts and 
a sample set of colours to work with.

thoughts?

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20081106/2beea240/attachment-0001.sig