C M wrote:
I know this comes up from time to time. I am trying to have a gradient
as the background of a panel and have managed to come to some success,
but it is not all the way there yet. So I have two questions:
- Would it be possible for wxPython to have a good approach for doing
gradients, one that automatically dealt with the issues I will describe
in the next point? I think this would be valuable. Gradients are
“just” aesthetic, but aesthetics matter, I feel, and they are fairly
highly associated these days with professional-looking software. Having
to do some of the tricks that have been discussed on this group lately
strikes me as unfortunate (I know, you can’t have everything, but I am
just throwing this out there).
- Until that time, here is my issue. I have enclosed a runnable
sample. What I’ve done is placed a few controls (using sizers) on a
gradient background, and, since wxStaticText forces you to see the
background and thus breaks the gradient there,
That depends on how you look at it. What you are actually seeing is the
static text’s background, not the panel’s or frame’s. So in one sense
it is doing exactly what you are telling it to do (since you are not
telling it to paint its own background in any special way.) It’s
unfortunate that programming languages have such a hard time making the
do-what-I-mean-not-what-I-say leaps of intuition.
One easy way to work around this is to set the background of the static
text to something between your gradient’s start and stop colors. If you
get it right and your gradient’s rate of change is not too high then it
will be hard for the eye to detect that there is actually a solid colour
there. If you are calculating your own gradients or other background
style then you can use the position of the widget to figure out what
exact color to use.
First of all, thanks, Robin, so much for these answers–super helpful, as always, and I always learn a lot at these times! The changes work very well to stop the flickering in its tracks.
Though I will try this work around of matching the staticText’s background to the local area’s color in the gradient, though there is a problem if the user resizes the frame, since then the gradient changes to match that new size and then the background will stand out more.
That’s because you are using the Frame’s paint event to draw on the
panel, so the order that the painting is happening is backwards. First
the frame’s paint event happens and so you draw the text on the panel,
and then the panel’s background erase event happens and you draw the
gradient over the top of the text. Changing the paint event handler to
be bound to the panel’s EVT_PAINT fixes this.
Again, very useful to understand the mechanics of this.
This is the problem that a double buffering technique will solve.
Excellent, and good to know.
My point (2) here is really not a great solution. There are other
problems with gradients. One is that buttons on a gradient have an
extra pixel or so grey border around the edges, which is not pleasant.
That’s simply the portion of their background that is visible.
Unfortunately, it seems that, at least for the wxButton, changing the background to match the local area color of the gradient isn’t a great solution, because the background color is actually most of the color of the button (changing the background to green creates a green button, basically, and I’d rather have standard light grey buttons). If the button is on a grey background it is not noticeable, but I might want to have colored gradients. Oh well. I might try something more like the ButtonPanel approach, using homemade buttons made from transparent PNGs, ultimately if I care about that one pixel border looking bad. (for now it is not a major issue).
Thanks, then, Robin!
···
On Wed, Mar 19, 2008 at 8:56 PM, Robin Dunn robin@alldunn.com wrote: