Two days ago I removed lots of unused code. The old code obscured the shape
of Leo's actual key-binding scheme. I have just updated the section << Key
bindings, an overview >> in leoKeys.py as follows::
The big pictures of key bindings:
1. Code in leoKeys.py and in leoConfig.py converts user key settings to
various Python **binding dictionaries** defined in leoKeys.py.
2. An instance of leoQtEventFilter should be attached to all visible panes
in Leo's main window. g.app.gui.setFilter does this.
3. leoQtEventFilter.eventFilter calls k.masterKeyhandler for every
keystroke. eventFilter passes only just the event argument to
k.masterKeyHandler. The event arg gives both the widget in which the
event occurs and the keystroke.
4. k.masterKeyHandler and its helpers use the event argument and the binding
dictionaries to execute the Leo command (if any) associated with the
incoming keystroke.
Important details:
1. g.app.gui.setFilter allows various traces and assertions to be made
uniformly. The obj argument to setFilter is a QWidget object; the w
argument to setFilter can be either the same as obj, or a Leo wrapper
class the supports the HighLevelInterface protocol. **Important**: the
types of obj and w are not actually all that important, as discussed
next.
2. The logic in k.masterKeyHandler and its helpers is long and involved:
A. k.getPaneBinding associates a command with the incoming keystroke based
on a) the widget's name and b) whether the widget is a text widget
(which depends on the type of the widget).
To do this, k.getPaneBinding uses a **binding priority table**. This
table is defined within k.getPaneBinding itself. The table indicates
which of several possible bindings should have priority. For instance,
if the widget is a text widget, a user binding for a 'text' widget takes
priority over a default key binding. Similarly, if the widget is Leo's
tree widget, a 'tree' binding has top priority. There are many other
details encapsulated in the table. The exactly details of the binding
priority table are open to debate, but in practice the resulting
bindings are as expected.
B. If k.getPaneBinding finds a command associated with the incoming
keystroke, k.masterKeyHandler calls k.masterCommand to execute the
command. k.masterCommand handles many complex. See the source code for
details.
C. If k.getPaneBinding fails to bind the incoming keystroke to a command,
k.masterKeyHandler calls k.handleUnboundKeys to handle the keystroke.
Depending on the widget, and settings, and the keystroke,
k.handleUnboundKeys may do nothing, or it may call k.masterCommand to
insert a plain key into the widget.
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
