Widgets tend to ignore SetBackgroundColor

Guys,

Last week I started updating the look of my App, and I ran into quite
a few widgets that ignore SetBackgroundColour() and
SetForegroundColour()... I believe with a few more functions like
SetHighlightColor or SetSelectColor or some such most widgets could
with several SetXColour()s at the top frame become completely
customizable.

I was wondering if anyone had put any thought to this. Thanks to
Gavana's AGW I was able to modify every widget I use except for the
menu bar and splitter window.

I've updated the wx.SplitterWindow class (ticket 11872) to allow it to
draw its own Sash in its background color and it looks perfect in my
app.

Since I need the menu bar next I'd love to have wx.MenuBar use a
background and foreground color. Though in this case it would need the
ability to specify a highlight color as well which would mean updating
wx.Window to add a similar function.

Is there a reason things haven't been done like this yet? After seeing
how good my app looks without all that gray I'm curious why this isn't
already in base widgets. AGW as well could create default renderers
that are enabled based on wxWindow's Background/Foreground color..

Yes. The native widgets may or may not support background or
foreground colors. If they do not support them, then you have to use a
generic widget instead. Remember, wxPython wraps native widgets
whenever possible, which has the advantage of the right "look-and-
feel". Of course, if the widgets weren't designed to allow certain
things, then there's a builtin disadvantage. Andrea's widgets are all
written in Python and are not wrapped native widgets...which is why
they're called Advanced Generic Widgets.

···

On Mar 31, 5:30 pm, Mark <markree...@gmail.com> wrote:

Guys,

Last week I started updating the look of my App, and I ran into quite
a few widgets that ignore SetBackgroundColour() and
SetForegroundColour()... I believe with a few more functions like
SetHighlightColor or SetSelectColor or some such most widgets could
with several SetXColour()s at the top frame become completely
customizable.

I was wondering if anyone had put any thought to this. Thanks to
Gavana's AGW I was able to modify every widget I use except for the
menu bar and splitter window.

I've updated the wx.SplitterWindow class (ticket 11872) to allow it to
draw its own Sash in its background color and it looks perfect in my
app.

Since I need the menu bar next I'd love to have wx.MenuBar use a
background and foreground color. Though in this case it would need the
ability to specify a highlight color as well which would mean updating
wx.Window to add a similar function.

Is there a reason things haven't been done like this yet? After seeing
how good my app looks without all that gray I'm curious why this isn't
already in base widgets. AGW as well could create default renderers
that are enabled based on wxWindow's Background/Foreground color..

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

Does every widget have a generic implementation? My point would
be that the widgets should be supporting background/foreground
colors and falling back to generic implementations to do so if
necessary.

For example the wx.Notebook should fill the area behind its
tabs in the background color otherwise you could not put a
notebook in a panel that isn't grey.

In addition to that I'm looking for someone to refute my statement
that given 3-5 colors ( background/foreground/highlight etc ) many
of the widgets could draw themselves in completely customizable
colors with a simple 5 lines of code setting those colors on the top
level frame.

If I wanted to implement this would there be a problem with me
adding a few new SetXXXColour functions in the wx.Window base
class?

Mark

···

Yes. The native widgets may or may not support background or
foreground colors. If they do not support them, then you have to use a
generic widget instead. Remember, wxPython wraps native widgets
whenever possible, which has the advantage of the right "look-and-
feel". Of course, if the widgets weren't designed to allow certain
things, then there's a builtin disadvantage. Andrea's widgets are all
written in Python and are not wrapped native widgets...which is why
they're called Advanced Generic Widgets.

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

Hi Mark,

Does every widget have a generic implementation? My point would
be that the widgets should be supporting background/foreground
colors and falling back to generic implementations to do so if
necessary.

I don't think there's a generic version for every widget...for
example, I don't think the grid has one.

For example the wx.Notebook should fill the area behind its
tabs in the background color otherwise you could not put a
notebook in a panel that isn't grey.

In addition to that I'm looking for someone to refute my statement
that given 3-5 colors ( background/foreground/highlight etc ) many
of the widgets could draw themselves in completely customizable
colors with a simple 5 lines of code setting those colors on the top
level frame.

If I wanted to implement this would there be a problem with me
adding a few new SetXXXColour functions in the wx.Window base
class?

Mark

That's a question for the wx-dev or wxPython-dev list.

···

On Apr 1, 10:56 am, Mark <markree...@gmail.com> wrote:

-------------------
Mike Driscoll

Blog: http://blog.pythonlibrary.org

Does every widget have a generic implementation? My point would
be that the widgets should be supporting background/foreground
colors and falling back to generic implementations to do so if
necessary.

The point of wrapping native widgets is that they are native and behave the same way in all applications that use them. Exactly the same things is done in wxWidgets all widget types for things like SetBackgroundColour and it is up to the native control whether it will do anything with that or not, and if not then at least you can be reasonably sure that it is also not doing it in other applications too.

Falling back to generic implementations opens its own can of worms that you as the user of wx would probably not want to deal with, and the developers of wx certainly don't want to do it either. For example it is possible that the same native widget on different versions of the same platform (say, win2k and win7) may be different, where one would support setting the bg color and the other would not. There is no way for us to tell at runtime if it does or not, so maintaining the code that decides when to switch to generic would be a nightmare. It's also possible that different GTK themes on the same machine would have differences, so it would be impossible there. Secondly, there would be a very real risk that doing a very simple thing like setting the background color could change the behavior of the application, because a totally different widget would be used and it would be very difficult to keep the generic version 100% in sync with the native version, especially since there can be some differences between the platforms or versions of a platform.

For example the wx.Notebook should fill the area behind its
tabs in the background color otherwise you could not put a
notebook in a panel that isn't grey.

In addition to that I'm looking for someone to refute my statement
that given 3-5 colors ( background/foreground/highlight etc ) many
of the widgets could draw themselves in completely customizable
colors with a simple 5 lines of code setting those colors on the top
level frame.

If I wanted to implement this would there be a problem with me
adding a few new SetXXXColour functions in the wx.Window base
class?

It doesn't hurt to try, but in order to be accepted it would probably need to have implementations for the major platforms, and there would have to be a platform API that would work with any kind of widget. For example, a single API that could change the selection color in a listbox, listctrl, and textctrl. (Otherwise you would have to provide implementations of the method for every class that needs to do it differently.) On the other hand, does it make sense to allow calling SetSelectionColour on a button or a checkbox?

···

On 4/1/10 8:56 AM, Mark wrote:

--
Robin Dunn
Software Craftsman