On Fri, 24 Mar 2017 06:36:13 -0500 "Edward K. Ream" <[email protected]> wrote:
I'm not sure if I understood Lewis's post or not. I wonder if it was a humorous way of pointing out that Leo already has solutions to most of the actual problems / workflows that these other tools address. Different solutions, but no reason to think there's one best solution. > Leo will soon have commands that make it easy to show/hide the body > pane or everything except the VR pane. These commands will give Leo > the essence of Quiver's Preview, Presentation and Full Screen modes. > Ditto for Jupyter notebook views. I have a problem with your use of the word "the" :-) I'd like support for multiple edit and render panes. But following in the vein of your comments and what I think Lewis was saying, that's ok - Leo's current UI is good. As a piece of software (the hidden relationships, perhaps), I think Leo should be (is?) flexible enough to support multiple editing components. I think more use of a publish / subscribe approach might be key to that - for new components moving forward, no need to refactor the existing tree / body. I wrote this stupidly simple class for publish / subscribe last night: https://gist.github.com/tbnorth/602ccb3bfa5b0f4c4527ea64c28b7dd3 it may be insufficient, but it will do as a starting point. The odd example using it without an instance points towards the possibility of storing listeners on `c`, in appropriate cases, without modifying other Leo code. Or at least keeping the modifications more localized / possibly even in a plugin. Cheers -Terry -- 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.
