Imo, Leo is at a solid, stable state. Sure, it could be improved, but it doesn't need to be.
My overall goal is to substantially improve Leo for Leo's existing users, either by adding major new features or by improving Leo's reach in the world. This post will discuss prototypes that further that goal. *Background* Leo's environment (the programming world) is shifting daily. WebAssembly promises to be an earthquake. Rust and WebAssembly demonstrate that there has been huge progress in type checking, to an extent I never dreamed possible. Both compilers can check their input in linear time, a remarkable feat. It's way too soon to know exactly how this will play out, so this is a good time to experiment with prototypes. And the easiest form of prototypes are thought experiments. Here are some ideas that I'll pursue this year, in roughly the order of importance: *node.js* One of my primary goals is finding a way to use Joe Orr's work. Playing with node.js (and maybe Vue.js) seems like a good place to start. However, this goal is murky, so this prototype may come later, if at all. *WebAssembly* WebAssembly is way too important to ignore. I'll play with WebAssembly, including WebAssembly hosted on the desktop <https://github.com/mbasso/awesome-wasm#non-web-embeddings>. *Rust, types, lifetimes and design* I've said many times that we programmers know (or think we know) the types of our objects. Rust shows the bounds of this statement. It's not really enough to know the types of objects, we must be aware of their lifetimes <https://doc.rust-lang.org/1.9.0/book/lifetimes.html>. Rust shows that making both lifetimes and types an explicit part of a language has big benefits. And yes, some drawbacks. Few Python programmers know (or care) about the lifetimes of our objects. I don't myself, except during startup and shutdown. As a thought experiment, it would be good to do a paper redesign of Leo's classes, focusing on lifetimes. That might show ways to improve Leo's classes. There is no reason to do this in Leo itself, but it would be useful design exercise, and might lead to other projects. *Qt Quick and generalized Leo windows* Qt Quick <https://doc.qt.io/qt-5/qtquick-index.html> is a framework for designing and loading Qt windows. Loading these windows is driven by QML <https://doc.qt.io/qt-5/qtqml-index.html>, a variant of XML. Optionally, users can use Qt Designer <https://doc.qt.io/qt-5/qtdesigner-manual.html> to create the QML. It might also be useful to generate QML from Leo outlines... Qt Quick is advertised to be highly dynamic, but that might only be possible using JS. We shall see. Qt Quick might revolutionize Leo's windowing scheme, *provided* that Qt Quick can be made dynamic using Python. Terry and I have wanted a more flexible windowing scheme for Leo. We want a flexible, general way to introduce (and use!) new panes. The present code is a bit of a nightmare. So a close look at Qt Quick is in order. *Fast tree redraw* This is Leo issue #1068 <https://github.com/leo-editor/leo-editor/issues/1068>. I've changed my mind: I'll certainly play with this project. However, I still have no commitment to folding this into Leo. *Summary* My overall goal is to substantially improve Leo *for Leo's existing users*, either by adding major new features or by improving Leo's reach in the world. Qt Quick might revolutionize Leo's windowing scheme, *provided* that Qt Quick can be made dynamic using Python. Other projects are more speculative. This posts lists projects in order of importance, but I'll do them in whatever order seems easiest. 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
