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
oh-so-fragile string.
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
complexity.
- Ditto for the code that translates user settings to "canonical key
representation".
- 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
k.strokeFromSetting.
This allows type-checking assertions in the code.'''
*Summary*
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
confusion!
I expect to be able to do this work in a day or three.
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
