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! On Sunday, September 22, 2019 at 7:31:20 AM UTC-4, Edward K. Ream wrote: > > 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 > <https://kaleguy.github.io/leovue/#/t/2/> 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 > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/57e9ec4a-d158-49ca-953b-e04fcd13aa03%40googlegroups.com.
