Chance favors the prepared mind—Louis Pasteur.
When I awoke just now I saw the answer to a question I didn't know my mind
was working on, namely, how to drastically simplify Leo's key handling
code, including the key settings. This is huge.
The work that prepared my mind:
1. The recent ipynb importer code. It uses nbconvert to translate a string
(the file's text) into a python data structure, that *contains *text, but
also contained bools and lists.
2. Recent work on converting Meta to Alt on MacOS. This reacquainted me
with the horrors of the code that converts a Qt key event into Leo's
internal representation. At present, this representation contains an
3. Yesterday's post on branches.
The Aha: *Don't use a string to do an object's work!*
*The plan*1. Just like with nbconvert, Leo's code that handles incoming Qt
key events will output a python data structure, say LeoKey, *not *a string.
2. Leo's code that translates user key settings will generate a LeoKey.
It's not clear what to do about the pane specifiers. It might well be an
auxiliary field of LeoKeys.
That's all! But the effects are widespread:
- The code that translates Qt keys to LeoKeys instantly collapses in
- Ditto for the code that translates user settings to "canonical key
- Ditto for code that prints/dumps keys and user key settings.
- There is no longer any need to distinguish between canonical and
non-canonical key *strings.* In particular, the infamous g.KeyStroke class
will disappear. It's docstring:
'''A class that announces that its contents has been canonicalized by
This allows type-checking assertions in the code.'''
The code that handles Qt key events (the key handler) and the code that
handles key-related user settings (the key setting handler) will *meet in
the middle* by producing a common data structure, a LeoKey. This structure
will *contain *strings, but will not *be *a string.
For example, the representation of Alt+Ctrl+s will have:
- a mods field: set(['alt', 'ctrl']). This is the big simplification.
- a key field of "s".
- a code field whatever the Qt key code is, for debugging.
- a pane field (set only by the key setting handler) of one of ('all',
'text', 'outline', 'body', etc.)
No more horrendous "canonicalizing" of key representations! No more
I expect to be able to do this work in a day or three.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to email@example.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.