While testing the mouseless operation of Leo I realized that the cycle- all-focus command doesn't work for tabs in the log pane that are not text widgets. Fixing this involved a surprising amount of work, none of which has been pushed yet.
Several good things will come of this lengthy detour: 1. The solution to many, if not all, of Leo's key-binding problems will be to connect Leo's eventFilter class to Leo's top-level DynamicWindow widgets. Why didn't I think of doing that ages ago? The affect of this will be to bind Leo's standard keys to *all* widgets that don't explicitly override the bindings. For example, the goto.py plugin creates a QLineEdit widget in the "Nav" pane. At present, Ctrl-Shift-Tab is not bound to cycle-all- focus in that QLineEdit widget, so the cycle-all-focus command doesn't work properly. In the new scheme, key events not handled by QLineEdit will get passed up to parent widgets, eventually being handled by the eventFilter attached to the DynamicWindow. Thus, eventFilter must handle all events for all widgets, but it does that already. As a result, Ctrl-g (and other focus-changing commands) should be bound *everywhere* in Leo. This is a big deal: it should never be necessary to use the Alt-Tab, Alt-Tab hack to put focus in the body pane. 2. I discovered other, unrelated problems with the cycle-all-focus command, which were relatively easy to fix. 3. The unit tests that I set up to test Ctrl-Shift-Tab do not work when run externally. After running tests externally for several days, it is annoying to have to run tests locally--I have to reload unitTest.leo whenever I change the code. Compared with the edit,alt-4,edit,alt-4 cycle, repeatedly reloading unitTest.leo seems glacially slow. The question is, could the nullGui simulate focus issues well enough to run unit tests of the cycle-all-focus command externally? Yes, in theory, but no in practice. It would indeed be easy to define a gui.focus_widget ivar, set by the various setFocus calls and returned by g.app.gui.getFocus. Alas, focus code is not enough: the nullGui would need a simulation of *all* widgets in Leo, including especially the widgets created by plugins. Clearly, plugins authors don't create such simulations, and I'm not going to add them myself. Otoh, plugins don't generally get loaded when running tests externally, but that means that the unit tests themselves can't test widgets that aren't loaded. In short, I think that running tests locally is the only practical method of testing gui code. Near Term Plans ============= The focus and key-binding work just "appeared" today. These are significant bugs that require an immediate fix, imo. The promise of ensuring that all widgets have access to Leo's default bindings is too big to ignore. When that work is done, I'd like to complete the first draft of the leoInspect module. I'd like to do this this week. I'll be leaving for Florida about December 2, and I'd like to tie up these loose ends before traveling. In any case, I'll be working every day in Florida, focusing on unit testing and fixing bugs. 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.
