GNOME Bugzilla – Bug 709544
gtk_search_bar_handle_event() should take a GdkEventKey
Last modified: 2018-04-15 00:10:19 UTC
gtk_search_bar_handle_event() https://developer.gnome.org/gtk3/3.10/GtkSearchBar.html#gtk-search-bar-handle-event takes a GdkEvent* that should "contain" (meaning, be, because it's a union) a GdkEventKey*. Surely it would be simpler if it just took a GdkEventKey*, which is what the GtkWidget:key-press-event signal actually provides: https://developer.gnome.org/gtk3/unstable/GtkWidget.html#GtkWidget-key-press-event If you need precedent, gtk_entry_im_context_filter_keypress() does this too.
is this causing any actual problem for bindings ?
Not a huge problem that can't be worked around (we already have in gtkmm), but it generally makes it harder for language bindings to just automatically generate their code.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new