[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Temporary KColorScheme change - hard-code some state colors
From:       Josef Weidendorfer <Josef.Weidendorfer () gmx ! de>
Date:       2007-09-18 17:31:14
Message-ID: 200709181931.14523.Josef.Weidendorfer () gmx ! de
[Download RAW message or body]

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

You both have QPalette::Disabled and QPalette::Inactive, and they are
very distinct, see description of QPalette:

"
 The color groups:
  The Active group is used for the window that has keyboard focus.
  The Inactive group is used for other windows.
  The Disabled group is used for widgets (not windows) that are
   disabled for some reason.

 Both active and inactive windows can contain disabled widgets.
 (Disabled widgets are often called inaccessible or grayed out.)

 In most styles, Active and Inactive look the same.
"

If in a given style, making all widgets inactive results in big color
changes/flashing, the style seems to be broken according to the last
sentence in the part I quoted.

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.

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.

Or perhaps a better way would be a widget method to ask which part of the
widget has to be redrawn given a set of color roles changing. And redraw only
if there is an non-empty area that has to be redrawn, given the color roles
that change in an activation change.

With something like this, and "In most styles, Active and Inactive look the same",
changing the activation state for every widget when activating a window, seems to
be the right thing to me. E.g. it would allow to only change some colors in scrollbars
like OS X seems to be doing (and Eclipse/GTK too, BTW).

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

Josef



[prev in list] [next in list] [prev in thread] [next in thread]