Leo isn't (all) about its gui :-)

[Edward K. Ream]

All of us spend a huge amount of time polishing Leo's look and feel.  This is natural, because this is what we see, all the time.

For me, though, Leo's gui is of secondary importance.  For users, what makes Leo special are outlines and clones, and closely related features such as the clone find commands.  Behind the scenes, what makes Leo special are true python objects for nodes, and closely related features such as per-node uA's.

These special features are what I most want to expand and explore.

However, other interesting projects beckon, especially the JavaScript world. There probably has been far more engineering work done on JS infrastructure than Python infrastructure.  Joe Orr's demo shows just how powerful the overall JS platform has become.

Otoh, exploring the JS world might quickly embroil me in a JS version of Leo's gui.  Yes, we already have LeoWapp (Leo as a web app, aka, Leo in a browser).  However, I'm not sure this is restful enough for Joe, whatever "restful" means...

Summary

Imo, thinking outside the gui box offers the greatest opportunities for useful invention.

The JS world beckons, but I don't want to do a new JS gui!

WebAssembly may offer a way to get the advantages of JS within Leo's present Python platform. That's probably a year or more away.  I won't jump into a major JS project until then.

All comments and suggestions welcome.

Edward

[Robert Cholette]

For me, as I see it, (i may be wrong, i'm not sober right now) Leo's gui was totally usable in early 2000's. I Never got into what was all that fuss with buttons, little command line at the bottom, vim/emac stuff... That all ate at the real-estate screen space that is supposed to show me the 3 things I want in Leo : outline pane, body pane and log pane. 

I'll admit that I'm being totally biased because i'm writing extentions to insert leo into other ide's : but I think leo's future development should focus on encapsulating leo's core and make them more easily available through a comprehensive API, to any external application/gui/presentation etc.. Not saying that leobridge is bad or anything, just wishing for more of the good stuff :)

A feature that I think is lacking in Leo is Ua's (custom user attributes in pnodes) relating to line numbering of derived files nodes (and their desendants) (@clean, @files, @nosent, @asis etc...) 

Those would be needed In order for Leo, or other GUI driving Leo, to interact with a debugger, or other tools, and bring the selection and focus to a particular line of text in the body of a particular node in a derived file.

To do so, the nodes need to have Ua's that are simple integers being the line number that correspondes to where the first line of their body text is, in relation to the derived output file. Along with the line number of the first line after an '@others' directive, and a matching list of numers for any other <<section references>> in a node. So a small array of integer perhaps. 

(first number if first line-number of node as it appears in the drived file, second is either for an @others next-line-number and the rest are line-numbers for each section refs, if any) This is how we did it in xcc nodes. (we didnt support section-refs though, so it was just first line-number of the node and a facultative line-number for an @others.)

This can be implemented by highjacking the file derivation process, or making a dry run just to get those numbers (without generating any file), and adding to Ua's as the file is being derived line by line while going node by node, bumping into @others and section refs... 
--

Those were just a few thought that came to mind reading this post :)

--

Félix

P.S. Major, complete rewrite of LeoInteg going on right now, as I know more about Leo's api & vsCode's api to warrant a total re-write of this expansion!

Cheers!

[Edward K. Ream]

On Sun, Sep 22, 2019 at 1:40 PM Robert Cholette <felix...@gmail.com> wrote:

Leo's gui was totally usable in early 2000's. I Never got into what was all that fuss with buttons, little command line at the bottom, vim/emac stuff... That all ate at the real-estate screen space that is supposed to show me the 3 things I want in Leo : outline pane, body pane and log pane.

Maybe that's all you want, but other people have other preferences.

I think leo's future development should focus on encapsulating leo's core and make them more easily available through a comprehensive API, to any external application/gui/presentation etc.

How do you propose to do that, without using Leo's bridge?

 

A feature that I think is lacking in Leo is Ua's (custom user attributes in pnodes) relating to line numbering of derived files nodes (and their desendants) (@clean, @files, @nosent, @asis etc...) 

I don't know what you mean by pnodes. Leo has positions and vnodes.

Leo has uA's, and extensive facilities for computing the line numbers (in external files) corresponding to lines in each node.  Leo's debugger already this.

Edward

[Robert Cholette]

Thanks for your reply! Indeed I was being self-centered in stating my preferences, obviously :)

yeah I meant positions, (i thought there were pnodes and vnodes, my memory is failing me it seems)

And also thanks for pointing me to to leo debugger's existence, didnt know about this!

--

Félix

On Sunday, September 22, 2019 at 7:31:20 AM UTC-4, Edward K. Ream wrote: