This post discusses my present thinking about key handling. I have abandoned the keys branch and created a new keys2 branch. The keys2 branch is a clean start, based on devel. The only survivor from the keys branch is a simplified eventFilter that should work *exactly* as before. That code has been merged to devel.
I have closed #858 <https://github.com/leo-editor/leo-editor/issues/858>, based on a faux-Eureka <https://groups.google.com/d/msg/leo-editor/iqD2cK7bxwY/lhoGIcg3CAAJ>, and started work on #423 <https://github.com/leo-editor/leo-editor/issues/423>, whose goal is to improve g.KeyStroke. Here is my plan: *Improve g.KeyStroke* As #423 <https://github.com/leo-editor/leo-editor/issues/423> says, g.KeyStroke should be more than a wrapper around a string. The ks.s ivar is evil and will be replaced by at two or more ivars: *ks.mods*: a list of (string modifiers), for example, ['alt', 'shift']. ks.mods will collapse the complexity of code throughout Leo. No more confusion about order of mods, or their spelling, or the separators between them. No more confusion about what the non-modifier part of the stroke is. *ks.char*: a unicode character. Perhaps ks.char should contain only *visible* characters. In that case, one or more ivars must represent... - Control (that is, non-visible) characters, like ctrl-s or Alt-1. - Quasi control characters like Home and End. - (Maybe) Strange key combinations on various keyboards. There must be some way to create a g.KeyStroke from user key bindings. Details fuzzy, and not too important here. *Simplify handling of Qt key events* Simplifying filter.eventFilter was a good start. The next step will be to simplify the code in the "filter.Key construction" tree. Much complexity is unavoidable, because of the inherent difficulty in deciphering what the dashed QKeyEvent actually means. Happily, room for improvement definitely exists: - A better g.KeyStroke class will avoid some complications. - Moving some dicts out of leoKeys.py so they are defined where used may also help. - As always, refactoring may help. This work should help clarify exactly what the ivars of g.KeyStroke should actually be. *Clarify names* Bad names create needless confusion. Here are some plans: The name "shortcut" means too many things, so it means nothing at all. I want to kill off as many uses of "shortcut" as possible. The names "ch" and "char" are also problematic. The new code should probably use names for temp vars that correspond to g.KeyStroke ivar names. Naturally, that requires that I figure out what the g.KeyStroke ivars actually mean ;-) The name "stroke" should *always* refer to a g.KeyStroke. At present, the "event" name refers both to LeoKeyEvent objects and Qt QKeyEvent objects. I am considering using the name "key_event" in k.masterKeyHandler in its many helpers. We shall see whether this makes sense... I'll rename g.ShortcutInfo to something like g.BindingInfo. The docstring for this class is: A class representing any kind of key binding line. This includes other information besides just the KeyStroke. At present, "si" refers a g.ShortcutInfo. This name is not used all that often, so it should have a longer name, say binding_info. *Improve style without changing classes* Yesterday's work showed me that I have been grossly misunderstood the g.TypedDict and g.TypedDictOfLists classes. For a long time I have thought there was something not quite right (un-pythonic) about these classes. But no, they are just dicts, with additional features. What *is* "not quite right" about these classes are all the assertions involving them. Those assertions are ugly, sclerotic and unpythonic. We don't typically worry about other dicts. Why should we worry about these dicts? These assertions are ironic, because these dicts do type checking! We can, and should, replace assertion on g.TypedDict and g.TypedDictOfLists with better names and naming conventions. That's *all* that needs to be done. Yes, these classes could be implemented as subclasses of dict, but there is no need or advantage in doing so. *Summary* The so-called Eureka <https://groups.google.com/d/msg/leo-editor/iqD2cK7bxwY/lhoGIcg3CAAJ> was misguided. It is the g.KeyStroke class that should be improved, not the LeoKeyEvent class. Adding ivars to g.KeyStroke will collapse code throughout Leo. These changes may have side effects. The g.new_keys switch will, as before, protect the old code from the new. Clearer names should make the code easier to understand. The g.TypedDict and g.TypedDictOfLists classes are fine as they are, but there is no need for asserts involving them. Edward P. S. Note to myself. Don't ever again use the word "Eureka" :-) EKR -- 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.
