Color, Icon and Font Settings in KDE4

[Aaron J. Seigo]

On Tuesday 03 April 2007, Matthew Woehlke wrote:
> 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

> ...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.

yes, that's my thinking as well. my concern with numbers is that there is 
abslutely no guidance and will end up getting used semirandomly or people 
will have to constantly reference documentation. but if there is one marked 
as "Security" or "New" then i can probably guess which is "closest" 
semantically.

> > - 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... 

yes, i was looking for some use case examples =)

> For example, the grepview widget in KDevelop has 'file name', 'result',
> 'command', 'errors', and 'output' (Ok, I think 'command' and 'errors'

perfect =) thanks..

> 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/.

agreed.

> I think we have these background roles:
>
> Workspace (currently known as "standard")

i'd rather not overload the term "workspace" further (we're using it on the 
desktop now to refer to desktop/panels/windowmanager/etc), but something 
better than "standard" would be nice indeed.

> 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.

i think the latter makes the most sense since that allows each set to be 
defined independently while keeping just one set of foreground colours for 
each.

> However I am thinking that "selected" and 
> "focused selected" need to be distinct (i.e. not shared with any other
> roles).

this sentence is a bit ambiguous; could you provide a bit more detail?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070404/30d76b19/attachment.sig>