After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 172842 - Expose event called on every focus in or focus out
Expose event called on every focus in or focus out
Status: RESOLVED NOTABUG
Product: pygtk
Classification: Bindings
Component: general
2.5.x/2.6.x
Other Linux
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
Depends on:
Blocks:
 
 
Reported: 2005-04-06 18:30 UTC by Akkana Peck
Modified: 2005-04-07 03:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test case for pygtk (1.13 KB, text/plain)
2005-04-06 18:31 UTC, Akkana Peck
Details
gtk test case in C (1.80 KB, text/plain)
2005-04-06 18:33 UTC, Akkana Peck
Details
Makefile for gtk C test (399 bytes, text/plain)
2005-04-06 18:33 UTC, Akkana Peck
Details

Description Akkana Peck 2005-04-06 18:30:08 UTC
Distribution/Version: Debian sarge, ubuntu hoary

Add a print statement to the expose event handler, then focus in and out without
changing visibility of the window.  pygtk thinks the entire window needs
repainting each time there's a focus change.  It's particularly obvious with
mouse focus, since expose is called twice every time the mouse moves over the
window.

I've tested this with three window managers: metacity, icewm, and fvwm (all
three in mouse focus mode).

This is specific to pygtk: it does NOT happen in a normal C gtk program, nor in
a C xlib program.  I will attach small test programs for both pygtk and C gtk.
Comment 1 Akkana Peck 2005-04-06 18:31:41 UTC
Created attachment 39762 [details]
Test case for pygtk
Comment 2 Akkana Peck 2005-04-06 18:33:01 UTC
Created attachment 39763 [details]
gtk test case in C
Comment 3 Akkana Peck 2005-04-06 18:33:37 UTC
Created attachment 39764 [details]
Makefile for gtk C test
Comment 4 John Finlay 2005-04-07 00:56:47 UTC
It's unlikely that PyGTK behavior differs from GTK+ behavior in this case. Your
PyGTK and C programs differ enough that little is proved by comparison. I was
able to make your PyGTK program behave like your C program by commenting out one
of the differing elements:

    #drawing_area.set_flags(gtk.CAN_FOCUS)
Comment 5 Akkana Peck 2005-04-07 01:18:06 UTC
Unfortunately, I to be able to get keyboard events on the drawing area, since my
program uses them.  The C gtk program can receive keyboard events on the drawing
area, and still does not generate spurious expose events, so there's still a
pygtk-specific limitation here.  Is there some other way to get keyboard events,
without calling drawing_area.set_flags(gtk.CAN_FOCUS) ?
Comment 6 James Henstridge 2005-04-07 03:08:38 UTC
GTK automatically queues a redraw for a focusable widget when it gets focused --
this is because most widgets provide some indicator that they are focused (in
fact, all widgets should provide some indication of focus if they are to be
accessible).

As John said, any difference in behaviour is probably due to differences in your
code, rather than behaviour differences between C and Python.  Try doing a
straight transliteration of your C example to check.