Try running embedding_in_gtk.py and moving another window
> partly in front of it, then click the embedding_in_gtk
> window to bring it back on top - does the window get
> redrawn?
> I can verify that on PyGTK 2.4 on Linux it works fine.
> Could you test it on PyGTK 2.6, and also report the
> operating system you are using.
I get the problem in Ubuntu Hoary Hedgehog ( 2.16.10 I think), with a
normal mpl pylab figure in GTKAgg. It is hard to see with normal
figure sizes, because the tooltips by default appear below the toolbar
and thus do not occlude the FigureCanvas, but if you resize the figure
so that it takes up the entire vertical extent of the desktop, and
then hover over the toolbar, the tooltips will occlude the canvas and
will expose the bug -- no pun intended 
The basic problem is that
the area occluded by the tooltip is not redrawn when, for example, you
hover over a different toolbar button.
JDH
John Hunter schrieb:
"Steve" == Steve Chaplin <stevech1097@...41...> writes:
> Try running embedding_in_gtk.py and moving another window
> partly in front of it, then click the embedding_in_gtk
> window to bring it back on top - does the window get
> redrawn?
> I can verify that on PyGTK 2.4 on Linux it works fine.
> Could you test it on PyGTK 2.6, and also report the
> operating system you are using.
I get the problem in Ubuntu Hoary Hedgehog ( 2.16.10 I think), with a
normal mpl pylab figure in GTKAgg. It is hard to see with normal
figure sizes, because the tooltips by default appear below the toolbar
and thus do not occlude the FigureCanvas, but if you resize the figure
so that it takes up the entire vertical extent of the desktop, and
then hover over the toolbar, the tooltips will occlude the canvas and
will expose the bug -- no pun intended The basic problem is that
the area occluded by the tooltip is not redrawn when, for example, you
hover over a different toolbar button.
JDH
As I mentioned in my post in the original thread the reason for this lies in the fact that you turn off GTK double buffering and try to provide your own buffering mechanism. Why can't you use both? From my first impression there seems to be no speed problems when I turn gtk double buffering on, but all the mentioned problems will be gone.
Niklas.
I've taken the pygtk list off of the reply-to addresses, I don't think
its their problem anymore.
I updated backend_gtk.py in cvs to remove the DBL_BUFFER code - it was
just an experimental feature and I do not think anyone had a use for it,
and it was confusing the rest of the code.
I added the call to self.window.clear_area() which should solve the
problem. Could someone using PyGTK 2.6 install from cvs and let me know
if it works.
Thanks,
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com
···
On Wed, 2005-06-01 at 20:44 -0500, John Hunter wrote:
> Try running embedding_in_gtk.py and moving another window
> partly in front of it, then click the embedding_in_gtk
> window to bring it back on top - does the window get
> redrawn?
> I can verify that on PyGTK 2.4 on Linux it works fine.
> Could you test it on PyGTK 2.6, and also report the
> operating system you are using.
I get the problem in Ubuntu Hoary Hedgehog ( 2.16.10 I think), with a
normal mpl pylab figure in GTKAgg. It is hard to see with normal
figure sizes, because the tooltips by default appear below the toolbar
and thus do not occlude the FigureCanvas, but if you resize the figure
so that it takes up the entire vertical extent of the desktop, and
then hover over the toolbar, the tooltips will occlude the canvas and
will expose the bug -- no pun intended The basic problem is that
the area occluded by the tooltip is not redrawn when, for example, you
hover over a different toolbar button.
JDH