Color, Icon and Font Settings in KDE4

[Matthew Woehlke]

Aaron J. Seigo wrote:
> On Saturday 31 March 2007, Olaf Schmidt wrote:
>> 1. The handling of colours, icons and fonts in KDE can be much improved.
>> You can find a description of useful changes here:
>> http://amen-online.de/%7Eolafschmidt/colors/colors.pdf
> 
> - why number the colours when there are semantics to them? in the table on 
> page 4 (table numbers would be nice =) the numbered colours are given 
> contexts in which they should be used. as a side note, i'd also 
> recommend "Secure" versus "Encrypted" 

...My understanding is "because the roles are suggestions". An 
application may want to use them for different purposes (of course, 
errors should always be a particular index, but that particular index 
need not be used only for errors). But I suppose it would help 
readability to give them names, if we accept that they will not always 
be used for exactly those purposes.

> - what sort of "new foreground colours" in addition to the color scheme would 
> be necessary? it's not very difficult to just spin around the colour wheel 
> staying within a certain contrast area, but knowing what the purpose of this 
> would be useful

This, unfortunately, is application defined... which is a good reason 
for the behavior above; we provide a set of stock colors that can be 
customized, and (for increased consistency) *suggest* roles for each.

For example, the grepview widget in KDevelop has 'file name', 'result', 
'command', 'errors', and 'output' (Ok, I think 'command' and 'errors' 
are the same). or branches/3.5 I fixed this (it was using hard-coded 
colors) to use normal text, 50% text/50% background, and link 
visited/unvisited for these colors. With Olaf's proposal I think it 
would use normal, 8 (comment), 2 (link unvisited) and 5 (error). Of 
course, an ideal would be if all of KATE's attributes would be able to 
leverage this so that 100% system colors are used in a default 
configuration.

At some point we need to codify what the 'common use' roles are; I don't 
think what's in the PDF should necessarily be considered 'law' yet, as 
it hasn't (to my knowledge) really been discussed yet.

As I see it, the most important thing here is to decouple foreground 
roles from background colors. Right now this is partly done, we have a 
different "normal" for each of "button", "window" and "selected". What 
we do NOT have is a "focused" background role, and distinct values for 
the "link visited/unvisited" colors depending on their background. This 
is mainly what needs to be addresses; getting a value of a foreground 
color must depend on both the foreground role /and the background role/.



I think we have these background roles:

Workspace (currently known as "standard")
Selected
Window
Button
Tooltip

Focused Workspace
Focuses Selected(?)
Focused Window
Focused Button

..so each of those needs potentially its own set of foreground colors 
for each defined foreground role. We can probably simplify things by 
saying that there is only one effective "focused" background set (i.e. 
all "focused" backgrounds must work against the "focused" foreground 
color set), or that each set must work against both the "focused" and 
"normal" background colors. However I am thinking that "selected" and 
"focused selected" need to be distinct (i.e. not shared with any other 
roles).

-- 
Matthew
Obscurity: +5