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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
