On Mon, Jan 23, 2017 at 7:54 PM, 'Terry Brown' via leo-editor < [email protected]> wrote:
Attached is a screen shot, which looks odd because the screen shot > software's omitting the window border. > I'm glad you included this. It provides good context for the discussion. > > Track - whether or not it follows the node node selection in the tree. > > Update - whether or not it updates when the content of its node changes. > > Recurse - whether or not the View part is rendered based just on the > current node, or recursively. > > Split▾ - a three state button, Edit / Split / View, whether to show > only the Edit or View components, or both. When showing both... kind > of reminds you of a Jupyter code + output display widget, doesn't it :-) > > Render just causes an update of the View component when Update is > disabled > > More▾ is where a bunch of other stuff will go, like selecting how to > render (HTML, markdown, execute code and render result as plain text or > some other format), only update once every N seconds for expensive > renders, etc. etc. > These are cool options. They remind me of the combo box in the jupyter html page that selects various views. > > In the (very alpha) screen shot, you can see the effect of Recurse > being checked in the View component (lower half), @others is replaced > with descendant nodes. > > The point of this widget is to provide a place for paired edit and view > widgets, or just one or the other. It manages all the tracking / not > tracking, updating stuff etc. > Excellent. The pairing is the hard part. I think it will be quite easy to add QScintilla as another editor > widget, where supported, and all the expected rendering widgets (HTML, > markdown, rst, etc. etc.). So in some respects this is > View-Rendered-4, with the advantage of hindsight of all the previous > View-Rendered work. But also recognizing that the same track / don't > track etc. controls View-Rendered needs also apply to non-singleton body > editors. As I write I realize I need to add "Follow", like track except > the tree jumps back to the editor's node when the editor's selected. > > The goal is to be resolutely non-singleton, and provide a small and simple > API for edit and view widgets. There will be a lot of view widgets, but I > assume very few edit widgets. Maybe just QScintilla, Leo's body editor, > and > maybe the CKEditor rich text editor. > All this sounds reasonable. The challenge, which I'm hoping Edward will help with ;-) will be > getting Leo's body editor to work - particularly the key binding part. I > realize that supporting Leo's sophisticated key bindings (modes, > abbreviations, control of other parts of Leo, e.g. moving tree selection > while in body editor) add a lot of complexity to implementing Leo's > interface, but are also a major part of Leo's strength. > That shouldn't be too difficult. See @file leoKeys.py-->class KeyHandlerClass-->k.Binding. This is crappy code, but it shouldn't be too hard to patch it further. Start with k.makeMasterGuiBinding. After you are through retching, you should be able to continue. > My plan is to make it work so well with QScintilla and all the > view rendering widgets the need to get the regular Leo body widget in > there will be overwhelming :-) > Good marketing. And great work, Terry. Not sure how this will fit in with the pyzo widgets. Eventually I would like to use pyzo widgets so that we can have a border for use by the debugger. Hmm. Iirc, pyzo uses scintilla, so maybe this is part of the migration path. 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.
