[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Hardcoded colors (was: Qt4 Themes)
From:       Sandro Giessl <sandro () giessl ! com>
Date:       2006-06-28 12:19:01
Message-ID: 200606281419.02066.sandro () giessl ! com
[Download RAW message or body]

On Wednesday 28 June 2006 11:17, Luciano Montanaro wrote:
> On Wednesday 28 June 2006 06:12, Remi Villatel wrote:
[...]
> I suppose having a look at the "user interface guideline" could help here:
> I don't think each widget should have its own enum, but if possible, a
> meaning should be assigned to various graphical elements,
>
> > There's also another nightmare for the style developers: the fixed
> > colors. All styles that I know of have a patch to counteract the fact
> > that Konqueror changes the color of its status bars. Mine goes even
> > further in preventing any PaletteChange() on all status bars because
> > Kate also has this bad habit. The Konqueror situation has been that
> > ridiculous for a long time already. Handling colors belongs to the
> > style. Konqueror shouldn't do more than "saying" this is the current
> > active status bar and the style would react as it sees fit. The toolbar
> > buttons are another example. The style has the choice in between drawing
> > a button or... a button... because of the fixed colors. All the styles
> > that draw a button only on mouseover --including mine-- are wrong
> > because KToolbarButton will draw the label with the buttonText() color
> > only when no button must be drawn. Funny situation indeed.
>
> Well, no hard-coded colors should be used. We probably need to have a look
> at color usage of the various applications, and put the various "logical
> colors" in a central place to change.

As far as I know Gunnar Schmidt from the HCI WG is working on color schemes 
for KDE 4, in order to eliminate hard coded colors for accessibility 
purposes? Gunnar, I would be interested in knowing more about it.
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]