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 leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to