On Friday 07 November 2008, Marco Martin wrote: > On Friday 07 November 2008, Aaron J. Seigo wrote: > > (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.. it's not about having a requisite amount of colours from the rainbow, i just don't want a morbid black-on-black that also happens to make it ore difficult to see, for instance, which is the active window. the tasks widget, as it is right now with black-on-black, makes it really hard to see which is the active window. why? lack of contrast between foreground and background. in a well lit room, it's really, really quite bad. at night in a dark room i can see it a bit better. so we end up with a muddy interface that says either "i'm wicked cool, just not in a practical way" or "hey look, i'm darkness and death" (depend on how you take it) > 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 so we screw people who use their whole screen, and continue to ignore that black-on-black reduces contrast liiting usabilty and does indeed step over the border from elegant and into depressing. fascinating. > > 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? the problem is that kcolorscheme is not designed for this at all. going through the enums and the foreground/background/etc splits .. it's not at all how we line things up in plasma, since the foreground can very depending on whether the applet uses the standard widget background, sits on the desktop or in a panel area. > so besides window, button tooltip etc we would have a panel group... and for widgets that use something other than StandardBackground? > 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) this is an implementation detail, it doesn't inform us on how the API that faces the applet writer should be made, really. and colorFromImage there would require applet writers to know what the background image is, something we've successfully kept away from them. i'm beginning to lean towards an Applet::color(Plasma::ColorRole, <some other param(s)?>) API. that limits the additional classes, can encapsulate whatever the implementation is and can use information about the current state of the applet (e.g. what background it is using) to choose what color value to return. -- 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
