Re: An avalanche of new thoughts

[Edward K. Ream]

On Thu, Feb 1, 2018 at 1:40 PM, 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.
>

​Thanks for the confirmation. Your comments make this approach more likely.

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.

Re: An avalanche of new thoughts

[Joe Orr]

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

On Wednesday, January 31, 2018 at 12:12:01 PM UTC-5, Edward K. Ream wrote:
>
> 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 -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
>

-- 
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 

Re: An avalanche of new thoughts

[Edward K. Ream]

On Wed, Jan 31, 2018 at 11:12 AM, Edward K. Ream 
wrote:

- *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

-- 
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.

An avalanche of new thoughts

[Edward K. Ream]

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 -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

-- 
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.