Re: [gtk-list] Re: New key-binding system

[Owen Taylor <otaylor redhat com>]

matt <matt@cgibuilder.com> writes:

> > Whenever a keystroke is received for a widget, and the
> > widget doesn't handle it directly, a _binding_ for
> > that keystroke is looked up by the default handler.
> > 
> > A widget that wants to pre-process keystrokes before
> > looking up the bindings can invoke the lookup directly
> > from its key_press_event handler
> > 
> 
> So you are saying that the key_press_event handler has to call
> a function to insure that each keypress is handled like the user
> thinks it should be? 
> 
> example:  the user is in vi command mode in an entry widget.  
> if the user hits a 'l' i don't think the key_press_event handler 
> should be called.  
> 
> if it is called then the handler doesn't know if 
> the 'l' key was pressed in insert mode or command mode.
> 
> This is why i think the binding method should choose
> if and when all signals are sent out.

Basically, I don't think it is possible to write a VI
binding without support from the widget. The binding setup
is not a full language - it has no concept of variables or
conditionals - so it cannot maintain an internal
state. Without state, you don't have VI.

So, basically, there would be a action signal like:
  
  "toggle_command_mode"

In insertion mode, the Text widget's key_press mode first
handles the literal insertion of keys, then activates the
binding; in command mode, the Text widget first activates
the binding, and if no bindings matched, it then inserts the
key literally.

I'm not a a VI expert (or user), but I think this should
handle at least the basics. (Obviously, you don't get
the ':' commands, etc, but I think that is beyond the
scope of keybindings; just as an emacs mode isn't
all of Emacs, a VI mode can't be all of VI)

Regards,
                                        Owen