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

[Owen Taylor <otaylor redhat com>]

matt <matt@cgibuilder.com> writes:

> Owen Taylor wrote:
> > 
> > Basically, I don't think it is possible to write a VI
> > binding without support from the widget. The binding setup
> 
> Right, each widget is going to store a little extra data.
> 
> > 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"
> 
> I'm against adding signals just to add new bindings.  the current
> bindings don't need this signal so adding bindings shouldn't as
> well.

But, we have just agreed, right, that without making the
bindings language a "real" language - we need to modify
the widgets to support the concept of VI bindings, there
is no way around it.

[ I'll refrain making any implications about the what
  this implies about the wisdom of stateful key-bindings
  in the first place ]

 
> > 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)
 
> This is what i think should happen.   The user hits a key.
> the key sequence is passed a function like  bindkey(entry, keycode).
> 
> bindkey determinds if it should insert the character into the
> entry and send out a signal.   
> 
> bindkey keeps all the state info updated in the entry. 

Perhaps I misunderstand this proposal, but it seems to be
"put VI bindings directly into the Entry/Text/etc. widget's
C code". I don't see this as very appealing,

> I don't know if the emacs keybindings send out a signal for motion
> commands, but i know that vi bindings' of motion commands MUST NOT
> send them out.  
>
> it would confuse the hell out of the programmers and gtk programs.
> 
> I guess what i am trying to say is lets not make any more signals for
> the programers to worry about.  Lets just keep the ones we have, and
> let vi, emacs, windows, mac, and joe binding functions determine 
> how text is inserted and signals are sent.

Programmers do not need to worry about signals they do 
not know about. So, what is the problem? 

Action signals sort of turn things around a bit, from one
perspective - instead of being a way of communicating from
GTK+ to the application, they are a way of communicating
from the binding to signals. [ Though, sometimes, as in
"exec-script" from the binding to the application ]

Regards,
                                        Owen