Grabs and completions


I'm trying to understand why bug #639842 happens.  It's pretty easy to
reproduce on 3.0:

1. gtk+/tests/testfilechooser --action=save
2. type "/home/" plus the first letter of your username
3. wait for the completion suggestion window to appear
4. hit Tab
5. The focus changes to the next widget, while it should in fact
complete your username (for example).

I have this stack trace of the place where the focus is changing:

#0  gtk_window_focus (widget=0x80ae070, direction=GTK_DIR_TAB_FORWARD)
at gtkwindow.c:5894
#1  0xb7587778 in _gtk_marshal_BOOLEAN__ENUM (closure=0x8098d98,
return_value=0xbfb5c480, n_param_values=2, 
    param_values=0x80eb540, invocation_hint=0xbfb5c49c,
marshal_data=0xb77201a1) at gtkmarshalers.c:165
#2  0xb6c8f947 in g_type_class_meta_marshal (closure=0x8098d98,
return_value=0xbfb5c480, n_param_values=2, 
    param_values=0x80eb540, invocation_hint=0xbfb5c49c,
marshal_data=0xb0) at gclosure.c:878
#3  0xb6c8f636 in g_closure_invoke (closure=0x8098d98,
return_value=0xbfb5c480, n_param_values=2, param_values=0x80eb540, 
    invocation_hint=0xbfb5c49c) at gclosure.c:767
#4  0xb6ca81ad in signal_emit_unlocked_R (node=0x8098df0, detail=0,
instance=0x80ae070, emission_return=0xbfb5c5bc, 
    instance_and_params=0x80eb540) at gsignal.c:3290
#5  0xb6ca73c3 in g_signal_emit_valist (instance=0x80ae070,
signal_id=37, detail=0, 
    var_args=0xbfb5c690 "\244Ƶ\277\364\177\203\267\310Ƶ\277\243\300p
\267") at gsignal.c:2993
#6  0xb6ca7623 in g_signal_emit (instance=0x80ae070, signal_id=37,
detail=0) at gsignal.c:3040
#7  0xb770b10f in gtk_widget_child_focus (widget=0x80ae070,
direction=GTK_DIR_TAB_FORWARD) at gtkwidget.c:9546
#8  0xb74fae65 in gtk_entry_completion_key_press (widget=0x81f8000,
event=0x80df318, user_data=0x80a25e8) at gtkentry.c:9572
#9  0xb758758a in _gtk_marshal_BOOLEAN__BOXED (closure=0x8310430,
return_value=0xbfb5c870, n_param_values=2, 
    param_values=0x80eb590, invocation_hint=0xbfb5c88c,
marshal_data=0x0) at gtkmarshalers.c:85
#10 0xb6c8f636 in g_closure_invoke (closure=0x8310430,
return_value=0xbfb5c870, n_param_values=2, param_values=0x80eb590, 
    invocation_hint=0xbfb5c88c) at gclosure.c:767
#11 0xb6ca7fe8 in signal_emit_unlocked_R (node=0x8099530, detail=0,
instance=0x81f8000, emission_return=0xbfb5c9ac, 
    instance_and_params=0x80eb590) at gsignal.c:3252
#12 0xb6ca73c3 in g_signal_emit_valist (instance=0x81f8000,
signal_id=49, detail=0, 
    var_args=0xbfb5ca80 "\230ʵ\277p&\t\b\001") at gsignal.c:2993
#13 0xb6ca7623 in g_signal_emit (instance=0x81f8000, signal_id=49,
detail=0) at gsignal.c:3040
#14 0xb77050ae in gtk_widget_event_internal (widget=0x81f8000,
event=0x80df318) at gtkwidget.c:6063
#15 0xb770493b in gtk_widget_event (widget=0x81f8000, event=0x80df318)
at gtkwidget.c:5779
#16 0xb74ff16b in gtk_entry_completion_popup_key_event
(widget=0x80e6150, event=0x80df318, user_data=0x80a25e8)
    at gtkentrycompletion.c:906

That gtk_entry_completion_popup_key_event() is gtkentrycompletion's
callback for "key-press-event" on its little popup window.  In turn,
that popup window grabbed the focus and took a GTK grab for events on
the keyboard device (see the end of _gtk_entry_completion_popup()).

For the file chooser's purposes, I'd like to be in charge of the Tab
key, instead of letting gtkentry and gtkentrycompletion decide what to
do.  So I'm wondering how to keep them from processing Tab at all, even
within the special signal handlers for the popup window.  Should I just
add an internal function to let them know not to mess with Tab?  That
seems a bit inelegant, but if it's internals only...


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]