[RFC] Color usability time, take 2

Matthew Woehlke mw_triad at users.sourceforge.net
Tue Jun 5 01:47:04 BST 2007


Upon consideration of aseigo's suggestions, let's focus on /just/ the 
color roles for the moment...

Matthew Woehlke wrote:
> Currently we have a problem that applications wanting to distinguish 
> items by color have to invent their own system to do so, often leading 
> to hard coded colors. The suggestion (1) for dealing with this is to 
> have eight 'roles' (which would include the current "normal", "link" and 
> "visited"), IOW you now get colors via foo.role(BackgroundRole, 
> ColorRole) (note: ColorRole can also be 'Background').
> 
> Usage: many, many potential users :-)
> 
> Questions:
> What do we name the five sets? We have "window"*2 (e.g. text edit, 
> menus, both ow which might be called "window"), "button", "selected" and 
> "tooltip". How do we look up colors? We could build KColorPalette (see 
> also above) although maybe KStylePalette would be a better name? This 
> would be nice because we could fold in shade (above), but may cause 
> problems if someone is overriding the color palette. We could use also 
> either KGlobalSettings or KColorUtils (which I am assuming will hold 
> e.g. {dark,light}{en,Contrast}, shade, luma, contrast, etc).
> 
> Notes:
> In addition to the eight foreground roles (which includes "normal"), 
> there are additionally the roles Background, AltBackground, 
> FocusBackground and (I would like to add) ActiveBackground for each 
> role. Then there are light, midlight, dark, and shadow. It might be 
> beneficial to define these for each background set but that seems 
> overkill. We should allow everything to inherit from background set 0 
> (one of the 'window's).

Let's forget the light, midlight, dark, shadow for now, it's highly 
questionable if they have any place here, and besides we currently don't 
have these defined per role (unlike other roles).

Anyway, right now I'm leaning towards KGlobalSettings as the place to 
put this. Here's what the API would look like:

/**
  * This enum describes the color set for which a color is being
  * selected.
  */
enum ColorSet {
     /**
      * Views; e.g. frames, input fields, etc.
      */
     View,
     /**
      * Non-editable window elements; e.g. menus.
      */
     Window,
     /**
      * Buttons
      */
     Button,
     /**
      * Selected items in views.
      */
     Selected,
     /**
      * Tooltips.
      */
     Tooltip
};

/**
  * This enum describes the color being selected from the given set. All
  * roles are valid for all sets.
  */
enum ColorRole {
     /**
      * Normal background.
      */
     bgNormal = 32,
     /**
      * Alternate background, e.g. for use in lists. May be the same as
      * bgNormal.
      */
     bgAlternate = 33,
     /**
      * Tint color to indicate items which have input focus. May be used
      * as a foreground color for e.g. focus rects (not for text) or
      * mixed with bgNormal.
      */
     bgFocusTint = 34,
     /**
      * Tint color to indicate items which will be activated by clicking.
      * May be used as-is or mixed with bgNormal to draw decorations.
      */
     bgHoverTint = 35,

NOTE: I would like to have these two, plastik at least uses them and 
many styles could use bgHoverTint. There was a usability recommendation 
that /all/ styles obey bgFocusTint although of course at the user level 
it should be an option.

     // Foreground Roles
     /**
      * Normal foreground.
      */
     fgNormal = 0,
     /**
      * Second color, e.g. comments, items which are old, inactive or
      * disabled.
      */
     fgInactive = 1,
     /**
      * Third color, e.g. items which are new, active, requesting
      * attention, etc. May be used as a hover color for clickable items.
      */
     fgActive = 2,
     /**
      * Fourth color, e.g. (unvisited) links or other clickable items.
      */
     fgLink = 3,
     /**
      * Fifth color, e.g. (visited) links.
      */
     fgVisited = 4,
     /**
      * Sixth color, e.g. errors, untrusted content, etc.
      */
     fgNegative = 5,
     /**
      * Seventh color, e.g. warnings, secure/encrypted content.
      */
     fgNeutral = 6,
     /**
      * Eigth color, e.g. success messages, trusted content.
      */
     fgPositive = 7,
};

/**
  * Retrieve colors from the system color palette.
  * @return the requested color
  */
static QColor color(ColorSet set, ColorRole role);


(Sorry, no implementation yet. Also this would mean that the current KGS 
getters would call into color(), or vice-versa. Note: this does *not* 
change the return values of any existing color getters, i.e. we still 
ask the system about e.g. {View,fgNormal}.)

Also the foreground roles (names, suggested uses) are certainly not set 
in stone yet.

[1] http://amen-online.de/%7Eolafschmidt/colors/colors.pdf

-- 
Matthew
"In the beginning was the word, and the word was
content-type: text/plain" -- Martin Schulze





More information about the kde-core-devel mailing list