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