An avalanche of new thoughts
67 views
Skip to first unread message
Edward K. Ream
Jan 31, 2018, 12:12:01 PM1/31/18
to leo-editor
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 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. 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 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
Background
This particular avalanche was triggered by reading Kent's request for "node pipes". I have just created #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. 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 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
Edward K. Ream
Feb 1, 2018, 4:05:04 AM2/1/18
to leo-editor
- 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.
[snip]
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()
Terry's NestedSplitter class in leo/plugins/nested_splitter.py already has similar code. ns.get_splitter_by_name, the local "hunter" function in ns.add_adjacent, and ns.find_child all do a dynamic search.
Edward
Joe Orr
Feb 1, 2018, 2:40:22 PM2/1/18
to leo-editor
Not sure I understand what you mean by use browser as graphics backend, just wanted to note that it is definitely possible to make a desktop app with browser technology (Electron). Just need to wrap the backend in node.
Joe
Edward K. Ream
Feb 1, 2018, 4:08:05 PM2/1/18
to leo-editor
On Thu, Feb 1, 2018 at 1:40 PM, Joe Orr <joe...@gmail.com> wrote:
Not sure I understand what you mean by use browser as graphics backend, just wanted to note that it is definitely possible to make a desktop app with browser technology (Electron). Just need to wrap the backend in node.
Thanks for the confirmation. Your comments make this approach more likely.
Edward
Edward K. Ream
Feb 2, 2018, 6:14:07 AM2/2/18
to leo-editor
On Thursday, February 1, 2018 at 1:40:22 PM UTC-6, Joe Orr wrote:
Not sure I understand what you mean by use browser as graphics backend, just wanted to note that it is definitely possible to make a desktop app with browser technology (Electron). Just need to wrap the backend in node.
I have just created #684: Create a browser gui for Leo. This issue explains how to use browser technology in a desktop version of Leo. Most of the steps apply to any gui for Leo.
As this year's work on the console gui shows, it is possible to create a new gui for Leo without changing Leo's core in any significant way. This makes a browser gui for Leo feasible. Only the gui code itself will be aware of web/LeoVue technology. The rest of Leo will remain as a pure python desktop application.
Edward
Reply all
Reply to author
Forward
0 new messages