I have been working on this post for about a week. The way forward has just become clear:
The work in 2019 will be the foundation for this year's work. The work in 2020 will focus on bridges between programs. *2019 Retrospective* 6.0 Completed the switchover to Python 3. This is a happy development. 6.0 also added support for Qt docks, a prerequisite for several planned projects. 6.1 completed the pyzo_in_leo plugin. I *can't recommend this plugin*, but it may become valuable this year. 6.2 fixes all serious known bugs. It also uses fstrings throughout Leo's code base, which I think is worth the work. *2020: The year of the bridge* The focus this year will be on *relatively simple* bridges between various apps and tools. 1. Thomas's recent post re graaljs <https://github.com/graalvm/graaljs>is a great example. A few lines of code allows Leo to run javascript code from any Leo node. 2. A few days ago I discovered Bokeh <https://bokeh.org/>. This was an important discovery: - Bokeh's graphics libraries offer d3 <https://d3js.org/> capabilities in python. The VR (and VR3?) plugins should be able to support Bokeh fairly easily. - Bokeh's client/server architecture should provide a ready-made bridge to the Jupyter world. I'll be studying Bokeh in detail. 3. #1235 <https://github.com/leo-editor/leo-editor/issues/1235> (neovim) will depend on a bridge between neovim (a neovim plugin) and Leo. 4. #1384 <https://github.com/leo-editor/leo-editor/issues/1384> (pyzo) will depend on a bridge between pyzo and Leo. The pyzo_in_leo plugin should allow Leo to inject bridge code into pyzo itself. Alternatively, the pyzo_in_leo plugin could inject a full plugin architecture into pyzo. We'll see what's better... *Summary* This week I have been wrestling with a sense that last year's work was not particularly valuable. Now I see it will be a firm foundation for this year's work. The focus of Leo 6.3 will be on *relatively simple* bridges between Leo and other apps or libraries. graaljs <https://github.com/graalvm/graaljs> makes Leo a better platform for javascript development. Bokeh <https://bokeh.org/> may be the long-sought bridge between Leo and Jupyter. Bokeh is built on Tornado <https://www.tornadoweb.org/en/stable/>. I'll be studying Bokeh, Tornado, yoton <https://yoton.readthedocs.io/en/latest/>and other client/server tools, looking for the best way forward. This new focus came from becoming clear about what I *won't *do. See the Post Script for details. There are other items on the 6.3 list <https://github.com/leo-editor/leo-editor/issues?q=is%3Aissue+is%3Aopen+milestone%3A6.3+-label%3Abug>. #1269 <https://github.com/leo-editor/leo-editor/issues/1269> (Improve key handling) is the most ambitious. For now I shall focus on building bridges. All comments welcome. Edward P.S. This new focus is a result of becoming clear about what I *won't* do: 1. Last year we reached consensus that Leo will remain a desktop app. 2. Rust will remain an interesting sideline. The leo-in-rust branch will contain experiments with the rust language. I have no plans to contribute to this branch at this time. 3. Imo, live coding is a dead end. The cool demos are toys which can not be scaled up: A: *Graphics*: Any graphics-based demo could be more easily recreated with a slider that changes the graphics values. Alternatively, you could just put your graphics code into a Leo node and hit Ctrl-B when you are ready for a new run. You could create an @button node to rerun the graphics code on every Leo keystroke, but that's just silly. Most of the time you would either get a syntax error or a graph using an intermediate value. B: *Music*. Similarly, a "live" music app would be more usefully coded with sliders. C. *Apps*. Changing a large app on the fly is either silly, or dangerous, or both. I am not going to invest in learning the tools of the Pharo world. Otoh, browsing such tools lead me to Bokeh, so the time was well spent :-) 4. Yesterday I reviewed some of Offray's links re Pharo. The Hyperscope screencast <https://vimeo.com/81238285> shows how far ahead of its time Hyperscope was. There are obvious parallels between Leo and Hyperscope. The Hyperscope links are basically gnx's. Showing them on-screen is pretty geeky. Adding view options to links is even more geeky. Leo's clones are far superior. Hyperscope's transclusion of links would be one way to do #946 <https://github.com/leo-editor/leo-editor/issues/946>. Also, the Hyperscope way is much like #1279 <https://github.com/leo-editor/leo-editor/issues/1279>. It's not a high priority. EKR -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/d77af3da-68c6-45c6-8bfa-a183f57f767a%40googlegroups.com.
