[wx-dev] inheritable colours again

[Kevin Ollivier]

Hi Vadim,

On Aug 5, 2006, at 8:48 AM, Vadim Zeitlin wrote:

>  Hello,
>
>  I thought we fixed this problem already but as the thread starting  
> from
>
> 	http://article.gmane.org/gmane.comp.lib.wxwindows.general/45397
>
> demonstrates, we didn't. Basically the problem is that it seems to be
> currently impossible to make the background colour to apply to the  
> window
> and all of its children -- unlike, for example, foreground colour  
> or font.
>
>  I see the following solutions:
>
> 1. The one I proposed in the thread above, that is add new  
> SetBgRecursive()
>    method which would work as expected and change  
> SetBackgroundColour() to
>    behave as SetOwnBackgroundColour() currently does:
>
>    + Allows to change the background for the entire panel/dialog at  
> once
>    + Compatible with the current code
>    - SetBackgroundColour() inconsistent with SetForegroundColour()
>    - SetOwnBackgroundColour() becomes useless (same as  
> SetBackgroundColour())
>
> 2. Remove/deprecate SetOwnBackgroundColour(), document that
>    SetBackgroundColour() doesn't change the children background  
> explaining
>    that it's a bad idea with modern themed GUIs
>
>    + Simplest
>    - SetBackgroundColour() inconsistent with SetForegroundColour()
>    - Doesn't allow to change the background of the entire dialog at  
> once
>
> 3. Let SetBackgroundColour() behave as SetForegroundColour(), i.e.  
> change
>    the colour for the window and all its descendants at once.
>
>    + Allows to change the background for the entire panel/dialog at  
> once
>    + All methods behave in consistent way
>    - Incompatible with the current behaviour
>
>
>  What would you prefer? My order is probably 1,3,2. Or is there  
> something
> else/better to do?

Actually, since OS X controls have transparent backgrounds, on Mac,  
SetBackgroundColour already does result in the background color of  
its children changing when their own BG color isn't set. Similarly,  
any other port that supports transparent backgrounds will show this  
behavior as well. So there is no consistent "current behavior" for  
all ports, at least at this point.

Enabling the code in the "#if 0" block in wincmn.cpp seems to me the  
only simple way to get this all working correctly and make behavior  
consistent across ports. Do we know exactly what this code broke? I  
see the commit was made 19 months ago (rev 1.212) but neither the  
comment or the commit msg indicates precisely which ports, etc. were  
broke, so I think step one is to figure out what exactly gets broken  
by this, and determine a correct fix. Perhaps we should just enable  
it on HEAD and see how this affects things (maybe after 2.7.0), then  
come back and determine a proper fix for any cases it breaks.

Also, while searching I did find a commit from ABX (window.h,  
1.178/1.179) with the following commit message:

"In MSWUniv wxWindow and wxWindowMSW are different classes so we  
can't access some of protected members (catched only by Borland).  
Therefore some of the flags related to background needs reading API."

So I think we should also switch that code to using the  
InheritsBackgroundColour() and UseBgCol() functions ABX created to  
deal with this issue.

Regards,

Kevin



>  Thanks,
> VZ
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wx-dev-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wx-dev-help at lists.wxwidgets.org
>