Dennis, I have tried to answer the points you raised.
> To: "Padraig O'Briain" <[EMAIL PROTECTED]> > cc: [EMAIL PROTECTED] > 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 > _______________________________________________ gtk-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/gtk-list
