plasma, panels, colours

[Marco Martin]

On Friday 07 November 2008, Aaron J. Seigo wrote:
> 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)

hmm, dunno, i feel that a light panel with just some black elements really 
tends to scream hey look at me, look at me! and the panel would be a total 
alen compared todesktop widgets
i think the icons in the panel are kinda enough to give color and exit from 
black on black pattern..

perhaps it's possible to keep it rather in style but not sure (maybe similar 
to the active task button, but with a raised look insted of sunken)
and kinda agree with riccardo, with a light background maybe could look better 
with maximized windows, dark with not maximized ones

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

yeah, as you said would impact how theme class work, at least probably, so 
let's do it now if we do it.
so we basically need a dfferent set of colors depending were we are
isn't possible to add new custom roles to kcolorscheme, right?
so besides window, button tooltip etc we would have a panel group...

or even a more silly idea :)
put in the panel background svg some elements like hint-text-color hint-
background-color of the proper colors.
to fetch it unfortunately should have to be rendered the element to an image 
and sampled (even just a single pixel) maybe Theme::colorFromImage(path, 
elementId) would be a thing a bit heavy weight but done just once (maybe even 
cached)

Cheers,
Marco Martin

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