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 156948 - Incorrect implementation of gdk_window_add_filter() in gdk.c/gdk.everride (pygdk_filter_func_marshal is incorrect)
Incorrect implementation of gdk_window_add_filter() in gdk.c/gdk.everride (py...
Status: RESOLVED WONTFIX
Product: pygtk
Classification: Bindings
Component: gdk
2.3.x/2.4.x
Other All
: Normal normal
: ---
Assigned To: Nobody's working on this now (help wanted and appreciated)
Python bindings maintainers
gnome[unmaintained]
Depends on:
Blocks: 346280
 
 
Reported: 2004-10-31 08:26 UTC by Eduardo Gonzalez
Modified: 2018-08-17 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Eduardo Gonzalez 2004-10-31 08:26:42 UTC
Please describe the problem:
The C definition of the GdkFilterFunc() is:

GdkFilterReturn (*GdkFilterFunc)            (GdkXEvent *xevent,
                                             GdkEvent *event,
                                             gpointer data);

Where xevent is the native event to filter, event is a GDK event to which the X
event will be translated, and data is the user data set when the filter was
installed.

The filter function in python should be:
def filter_func(event, data): 

Where event is the *GDK event*  This is wrong because the GdkEvent is just a
shell used for translating the XEvent to a GdkEvent by hand.  (If you do this
you have to return GDK_FILTER_TRANSLATE.)  Because of this, the event.type in
the python filter function will always be gtk.gdk.NOTHING. 
pygdk_filter_func_marshal should be changed so that either the XEvent is
translated into a GdkEvent, or add the xevent to the filter_function.

*gtk/gdk.override: pygdk_filter_func_marshal

Steps to reproduce:
1. create a gtk.gdk.Window
2. perform gtk.gdk.Window.add_filter(filter_func)
3. in filter_func(event, data) print event.type 


Actual results:
It'll always print "<enum GDK_NOTHING of type GdkEventType>" On each event.

Expected results:
event should either hold a pre-translated XEvent, or xevent should be added to
the filter function.

Does this happen every time?
Yes

Other information:
Comment 1 Erik Grinaker 2005-02-04 10:49:07 UTC
I would like to at least try to fix this. Seems like we can either 1)
pre-translate the GdkEvent, or 2) provide the raw XEvent and the empty GdkEvent
as the C API does.

1 might be easier to use for developers, and wouldn't require an API change - on
the other hand, it might be less flexible, and the behavior is different from
the C API. In what situations would it be useful to do the translation manually?

2 would need an API change, by adding the XEvent as the first arg to the
callback. What is the policy on this? Is this an acceptable change for a minor
number release?

Finally; are there any good workarounds for this issue? Can one get the
currently handled event from somewhere else when in the filter callback?
Comment 2 John Ehresman 2005-02-07 16:39:47 UTC
The filter function needs to be given the platform specific event (XEvent on
X11, MSG on win32, ?? on framebuffer) and an uninitialized GdkEvent structure to
fill in.  Filters can be used to look at platform specific events that are not
directly translatable to gdk events, including custom event types.  The thing to
probably do is to pass the native event structure pointer in wrapped in a
PyCObject so that extension modules can be written that cast it to the correct
structure.
Comment 3 Martin Dengler 2008-06-01 23:53:51 UTC
is comment #2 still relevant?  It sounds like it would make this function useful for things like http://lists.laptop.org/pipermail/sugar/2008-May/006202.html .
Comment 4 Maxim 2010-10-01 19:22:45 UTC
I really need this, cause xklavier.Engine.filter_events requires GdkXEvent, but gdk calls filter func only with empty GdkEvent
Comment 5 André Klapper 2018-08-17 13:35:52 UTC
pygtk is not under active development anymore and had its last code changes
in 2013. Its codebase has been archived:
https://gitlab.gnome.org/Archive/pygtk/commits/master

PyGObject at https://gitlab.gnome.org/GNOME/pygobject is its successor. See https://pygobject.readthedocs.io/en/latest/guide/porting.html for porting info.

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect
reality. Feel free to open a task in GNOME Gitlab if the issue described in this task still applies to a recent version of PyGObject. Thanks!