Re: key bindings - gtk2

["Padraig O'Briain" <Padraig Obriain Sun COM>]

Dennis,

I have tried to answer the points you raised.

> To: "Padraig O'Briain" <Padraig Obriain sun com>
> cc: gtk-list gnome org
> Subject: Re: key bindings - gtk2
> MIME-Version: 1.0
> 
> On Tue, 16 Jul 2002, Padraig O'Briain wrote:
> 
> > handled or the toplevel is reached. If the keystroke has still not been
> > handled the toplevel checks for key bindings.
> 
> Are you talking about the key bindings API now?
> 
>   http://developer.gnome.org/doc/API/2.0/gtk/gtk-bindings.html
> 

Yes, I mean bindings such as Tab, Shift+Tab, Ctrl+Tab used to defined focus 
movement defined for GtkWindow by that API.

> Or are you just stating that the toplevel is the last to check when you 
> move upwards from the focus widget.

I meant that the toplevel is not checked when traversing from the focus widget 
to its parent and so on. Then the key bindings on that toplevel are checked.

> 
> > Within a widget the handling of the keystroke will call key-press-event
> > handlers defined for that widget. These should, among other things, check 
for 
> > key bindings defined for the widget.
> 
> Or probably this is using the key bindings API.
> 
> I think you explanation of the overall handling is very nice. Thanks a
> lot. What I still don't understand is where (and how) the above API is
> used.
> 

The description is a summary of what the function gtk_window_key_press_event() 
does.

The code in gtkwindow.c and for other GTK Widgets, e.g. gtkscrolledwindow.c, 
should give you an example of how the key binding API is used.

> What kind of objects is the above key bindings connected to. I wrote code
> like this that changed my scrolled window to use the arrow to scroll
> instead of ctrl-arrow:
> 
>     binding_set = gtk_binding_set_by_class 
>                     (G_OBJECT_GET_CLASS(G_OBJECT(scroll)));
> 
>     gtk_binding_entry_add_signal
>        (binding_set,
>         GDK_Up,
>         (GdkModifierType)0,			  
>         "scroll_child",
>         2,
> 	GTK_TYPE_SCROLL_TYPE, 
>         GTK_SCROLL_STEP_BACKWARD,
> 	G_TYPE_BOOLEAN,
>         FALSE);
> 
> And this seems to work fine. But this connects the binding to the scrolled
> window class. Is this always so? What if I just want to change it for one
> scrolled window.
> 

I do not think that you can change behavior for a signal object. I think that it 
must be changed for a class. Perhaps if you derive a class from 
GtkScrolledWindow and give it the behavior you desire.

> I've also seen that key bindings have some sort of priority
> 
> 
http://developer.gnome.org/doc/API/2.0/gtk/gtk-standard-enumerations.html#GtkPat
hPriorityType
> 
> How does this mix in with starting at the focus widget and move out. What
> if the parent widget have a binding of the same key with higher priority. 
> Or is this just to resolve the binding for one widget (I guess it is).
> 

When the key press event is processed for a widget, the key bindings should be 
checked. If you write a key-press-event handler for a class, it would be your 
responsibility to make sure it happens; check gtk_entry_key_press().

I do not know what the meaning or effect if GtkPathPriorityType is.

Padraig

> > I have not said anything about accessibility (atk) as I do not see its 
relevance 
> > to the topic. If you are further questions, I will try to help.
> 
> Well, I don't know anything about atk and have never used it. I just
> thought that if I make my key bindings work in the intended way it will
> probably be good for atk also. I just assumed atk might have been
> involved.
> 
> -- 
> /Dennis
>