Something totally unexpected happened today after reviewing the ancient items in leo/doc/leoToDo.txt. I see new directions for Leo, and new ways to think about old issues.
*Background* This particular avalanche was triggered by reading Kent's request for "node pipes". I have just created #667 <https://github.com/leo-editor/leo-editor/issues/667> for this request. The actual trigger was realizing how badly I had misunderstood Kent's request. Kent made his request explicitly in terms of the demo at the bottom of Light Table's main page <http://lighttable.com/>. Kent wasn't asking for a way to pipe data into p.b. That's trivial. Instead, he was asking for a way to "inject" data into the gui itself. For example, one might want to inject data into the body pane's *gui*, that is, c.frame.body.wrapper. That's considerably harder. And a whole lot niftier. The "snow pack" of the avalanche consisted of lengthy discussions in leo/doc/leoToDo.txt. In particular, Offray complains at length that software is way too hard to develop. Software is too sclerotic. *Flexible vs sclerotic* I asked myself: how can Light Table be so flexible? My answer (perhaps bogus?) was that Light Table is based on html/javascript/css. As a result, Light Table, through the js DOM, has full access to the visual components. This shaky conclusion has had many interesting results. I then asked myself, what parts of Leo are flexible, and which are sclerotic? - *Flexible*: Leo's scripting API and related DOM. Both are much better than good enough, and both are easily and fully extensible. - *Flexible*: Leo's plugin mechanism. Again, plugins are much better than just good enough, and plugins have unlimited flexibility. - *Flexible*: Leo's abstract panes. The console gui plugin drives Leo's tree, body and log panes without any interaction at all between Leo's commands and the actual body code. That is, all of Leo's commands are insulated from the details of the particular gui in effect. - *Sclerotic*: Leo's @shortcuts nodes mix all pane bindings together. Instead, Leo could use @data <pane>-shortcut nodes that are inheritable. Like this: - @data text-shortcuts: definitions for *all *text widgets, unless overridden in children. - @body-shortcuts (overrides for the body pane) - @minibuffer-shortcuts This would provide a way of defining *key tables* for each *individual *widget. This would greatly simplify Leo's internal processing. - *Sclerotic*: Leo's concrete gui code. Terry has made Leo's gui more flexible than it was, but Qt seems to be showing signs of age. In contrast, web development continues to gain momentum. Joe Orr's LeoVue project highlights what can be done with off-the-shelf web components. Imo, Leo is always going to be a desktop app, but I am thinking that Leo might use a browser as the graphics back end. Leo could simulate the js DOM with a new Leonine API. For example, it would be possible to simulate getElementByName by searching through Leo's Qt widgets, using widget.parent(), widget.children() and widget.objectName() - *Partially sclerotic*: Leo's rendering tools. The rst3 command is flexible, but uses horribly complex code in the background. Similarly remarks apply to the VR and VR2 plugins. Perhaps we are suffering from vue.js envy. The soon-to-be-created new rendering enhancement requests suggest possible ways forward. - *Partially sclerotic*: Leo's attribute handling. The newly renamed #588 Make node attributes visible, with support in Leo's core <https://github.com/leo-editor/leo-editor/issues/588> aims to make attributes more flexible *and* more visible. Along with type-related Leo directives, it might be good to make rendering-type "bits" visible in all headlines. *Summary* There is a lot to chew on here. The overall goal is render Leo's gui in the niftiest, most flexible manner possible. It may be that web/javascript tools will be the new path forward. I will be creating about 30 new enhancement requests as time allows. They may suggest new ways to make Leo more flexible. All comments welcome. Please try to avoid dissertations ;-) 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 leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
