On Fri, Jan 8, 2010 at 10:19 AM, Edward K. Ream <[email protected]> wrote:
> The plan will be to define method in qtQui.py that will override > (monkeypatch) Leo's commands such a next-line, next-line-extend- > selection, etc. The new methods will simply generate a key event. This is almost certainly a bad idea: it mixes the implementation of commands with bindings. The situation is complex, and something simple like this has almost no chance of "just working". OTOH, today's work is far from a waste. It has brought me up to speed on the (unavoidable!) complexities involved. I have great confidence that some proper solution will be found. Let's review the situation: 1. The dictionaries in Leo's core are essential for flexible handling of key bindings. See the section << about key dicts >> in leoKeys.py for details. 2. It would be difficult, or impossible, and unwise to boot, to attempt to implement next-line by synthesizing an arrow key event and passing it on to Qt. Unless something messy is done, that key will be passed *back* to Leo. Moreover, unless the key *is* passed back to Leo, it will be difficult to update Leo's status line. It's a tangled puzzle. 3. We must be sure not to build in assumptions about what key binding will be bound to various commands. 4. There is some truly horrendous code in the eventFilter method in qtGui.py. I have some ideas for simplifying the code, but that will have implications both for bindings in leoSettings.leo and for code in k.masterKeyHander and its helpers. Like I said, it's a puzzle :-) Edward
-- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
