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

[matt <matt cgibuilder com>]

Owen Taylor wrote:
> 
> I've been offline for a while getting moved to Redhat here,
> and I see that a lot of effort has been expended on the
> discussion of key-bindings.
> 
> In the GTK+-1.1 currently in development, there is already a
> start at a flexible, configurable key-binding system.  To
> give people something other than vi-emacs to talk about,
> I'll briefly describe what is there and what the plans are:
> 
> Basic concept:
> =============
> 
> 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.

> Keystrokes are bound to a series of "action signals"
> which are just regular signals that were marked as
> actions when they were created.
> 
> [ The details of examples below are rather invented, and are
>   meant to show mostly the system, rather than the particular
>   action signals that
> 
> For instance, in the rcfile, you might have:
> 
>   bind "<Control>c" { "cut-clipboard" () }
> 
> or, rather fancifully,
> 
>   bind "<Control><Shift>p" {
>     "move-to-column" (0)
>     "insert-string" ("(")
>     "move-to-column" (-1)
>     "insert-string" (")")
>   }
> 
> Arguments can be specified for passing to the signal -
> they can be integers, strings, or even enumerations:
> 
>   bind "prior" { "move-vertically" ("page", 1) }
> 
> Where 'page' is an nickname for GTK_MOVE_PAGE.
> 
> 
> Lookup:
> ======
> 
> Bindings are grouped into named binding sets:
> 
> binding "myeditable" {
>   bind "<Control>c" { "cut-clipboard" () }
> }
> 
> The attachment of binding sets to particular widgets
> is specified, as for styles, by patterns:
> 
>   # bind all spinbuttons under MyWindow to "myeditable"
>   widget "MyWindow*GtkSpinButton" binding "myeditable"
> 
>   # bind all entries within a GtkSpreadsheat widget
>   widget_class "*GtkSpreadsheet.GtkEntry" binding "myeditable"
> 
> A new type of pattern has been introduced which binds
> to a particular branch in the class heirarchy.
> 
>   # bind all widgets that derive from GtkEditable
>   class "GtkEditable" binding "myeditable"
> 
> This now works for styles as well.
> 
> Priorities
> ==========
> 
> When multiple binding sets are attached to the same widget,
> resolution is done:
> 
>  - First, by priorities that can be given explicitly
> 
>   class "GtkEditable" binding : rc "myeditable"
> 
>   [ Syntax not final ]
> 
>  - Second, by the order in which the patterns were given.
>    Later patterns override earlier ones.
> 
> The three standard priorities are, in increasing order,
> 'gtk', 'application', and 'rc'. This is meant so that
> bindings can reliably be overriden, without worrying about
> the order they were given. Generally, the default 'rc'
> priority for rc-files will be the only thing ever used in an
> rc-file.
> 
> Also, when rc-files are reparsed with gtk_rc_reparse_all() [
> New in 1.1 ], only bindings at the 'rc' priority are
> cleared; because widgets and applications may create their
> own defaults with gtk_rc_parse_string() [ or directly with
> function calls on the gtk_binding API ]
> 
> Current Status
> ==============
> 
> Currently, pretty much everything except the actual parsing
> of the RC files is there. Anyone who wants to take a look can
> download the gtk+ module from:
> 
>   http://www.gnome.org/software/anoncvs.shtml
> 
> Since I think that we've drifted a bit too much into a
> "closed" development model here, let me mention that if you
> would like to be added to the list where we discuss random
> details of exactly what we are changing in GTK+, drop me an
> email. (Though we'll continue as currently to try to post
> anything of even slightly general interest here)
> 
> Regards,
>                                         Owen
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null