Temporary KColorScheme change - hard-code some state colors

[Matthew Woehlke]

Josef Weidendorfer wrote:
> [Apologies if the following is obvious for everybody; I did not read the
>  full thread]
> 
> On Monday 17 September 2007, Richard Dale wrote:
>> On Monday 17 September 2007, pinheiro wrote:
>>>> No, the hack to use the inactive control color palette for entire windows
>>>> is just broken and can never be made to work properly.
>>> Plese explain me how come? sory coding is not my experties.
>> The active/inactive palette api and visual appearance is designed for showing 
>> enabled/disabled controls within a window.
> 
> According to the Qt4 documentation, this statement wrong.
> [snip]

YSHFRTT :-) (http://www.cygwin.com/acronyms/#YSHFRTT). Richard already 
noticed.

> However, pure Qt code does not seem to use the QPalette active/inactive
> feature in the documented way; at least, while looking into the Qt source,
> I did not find anything useful in this regard.

For the most part, it does actually work, although there are a few bugs 
in list/tree views.

> Anyway, this should be the way I expect it to work to give minimal "flashing"
> when the window changes from active to inactive or vice versa:
> (1) A widgets can be asked about the color roles it uses to paint itself    
> (2) On a QEvent::ActivationChange, it checks if for the used color roles (see 1),
>     there is a color change involved with the activation change. Only if yes,
>     the widget is updated.

AFAIK this is already what happens. Alas, repainting widgets isn't 
entirely painless, more so with oxygen in its current state (we need to 
do more pixmap caching; it's on my TODO list).

> And yes, this should be configurable if a given style is broken.

It is configurable :-). There is just no (working) kcm yet (but I'm 
already hacking on my kdeglobals for testing purposes).

-- 
Matthew
<.sig snipped because someone might take it the wrong way in this thread>