Color, Icon and Font Settings in KDE4

[Matthew Woehlke]

Ping?

Matthew Woehlke wrote:
> Olaf Schmidt wrote:
>> The feature plan contains a usability and accessibility review period 
>> that has not yet started.
>>
>> We nevertheless decided to forward some of the already known issues to 
>> kde-core-devel earlier to make it easier to fix them before the full 
>> API freeze.
>>
>> 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
>>
>> Qt designer mockups are also available:
>> http://amen-online.de/%7Eolafschmidt/colors/designer.tar.gz
>>
>> We are aware that it would be unrealistic to expect everything to be 
>> change in time for KDE 4.0, but it would be nice if at least the 
>> colour scheme system could be updated soon.
> 
> I still have not heard about any progress here. Is this something we are 
> willing to tackle for KDE4?
> 
> I'm starting work on porting my personal KStyle, now known as Ion, to 
> KDE4, which puts me in a position to look at doing an implementation of 
> this.
> 
> What is needed:
> 
> - Support for additional color roles. We should provide a way to request 
> foreground colors based on the background role, which is one of 
> Input[1], Window, Button, Selected and Tooltip. Fortunately the painter 
> should know which one of these is in use. This will be done similar to 
> how we have a request for other not-in-Qt colors e.g. alternate list 
> background.
> 
> - Color blending support. We already need this anyway, but to implement 
> focus tinting effectively this is a MUST!
> 
> - Back-end support. Basically we should modify the QPalette seen by the 
> style for things that have focus. Any suggestions on how to accomplish 
> this? Fortunately this is slightly less urgent since it should be 
> transparent to developers, i.e. style and application writers should not 
> need to do anything special to support it, it will just magically 
> happen. An alternative (perhaps even a preferable one) is to pass a flag 
> specifying if the focus tinting should be used.
> 
> Since I didn't hear any better ideas or disagreement, I am going to 
> assume that we should implement focus tinting by... well, tinting. And 
> since there is a semantic difference between a window with focus, an 
> input area with focus, a selection with focus, etc, (not to mention 
> these can all be wildly different colors), I am thinking that a focus 
> tint per background role is the way to go. (Tooltips don't have focus, 
> so we only need four, not five.)
> 
> I'm also thinking maybe this should be on a wiki somewhere, is there a 
> good place to post this?

-- 
Matthew
"Doggy!" -- Robots from Freefall (http://freefall.purrsia.com)