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

[matt <matt cgibuilder com>]

Owen Taylor wrote:
> 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.

not that i can see.  we need to add a structure to the entry
that holds the binding data.  maybe we should force binding
creators to provide constructors and destructors of this data
before we include them in the release code.

so it sounds like we need to have three required functions.
construct_binding()
destruct_binding() 
bind_key()


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

Yes i know statefull keybindings are rather drugged, but i
and other like them so too much.

> 
> > > 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,

we add a structure to the entry:  void* bind_data;

it holds any and all information that any binding type/method/scheme
needs to know about the state of the widget. 

the user then somehow tells the library what binding method it wants.
the library then finds the correct  bindkey  function out of a list
of binding functions, and calls it.

> > 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?

Nothing, as long as the programer never has to know about it.
 
> 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 ]

OK, so all current apps will work the same way?  the signals are 
passed around inside the library?  if this is the case then i guess
this is what i am thinking should be done.

-matt wimer