On Wednesday, February 21, 2018 at 1:39:52 AM UTC-6, Edward K. Ream wrote:
I wrote my last post in the middle of the night. It shows :-)
After getting more sleep, and discussing the issues with Rebecca, more has
become clear. Here is what I think I know for sure:
*No forks, but...*
Leo's code base can't be allowed to fork, but *that's not a big constraint*.
Indeed, standard Leo plugins could communicate with *external hosts* such
atom, vscode, jupyter notebooks, eclipse, jEdit, etc. Let's call these Leo
python plugins *external gui plugins*. These Leo plugins would communicate
with *host plugins* in the external hosts. Host plugins could be written
in javascript (atom, vscode) or java (Eclipse) or python (jupyter).
*All *gui plugins, external or not, create two way communication between
the gui plugin (the screen) and Leo's core. That's what makes *any* gui
plugin difficult. Lockouts are usually needed. User actions create events
in Leo's core. Those events must be prevented from creating further actions
in the gui.
External gui plugins will communicate with the host plugins to do the
actual drawing. When opening a .leo file, the external gui plugin would
send a *representation *of the entire outline to host plugin. json or cson
should suffice.
The leoBridge will not change. Instead, external gui plugins *might*
launch a hidden version of Leo:
python launchLeo.py --gui=vscode
Leo itself will remain *almost completely unchanged*. The console gui
required about 10 benign new lines of code. We should expect (require!)
the same for any external gui plugin.
*What is Leo?*
- Vitalije asserts that @others is essential. I agree.
- The "no fork" rule means that Leo's core must remain unchanged.
- Python scripting access to Leo's code and data (c, g, p) is also
essential.
Many people are leery even of python. Forcing them to learn any variant of
javascript is out of the question. Support for any other scripting
language would require shims. We aren't going there.
*What do we want?*
- Not everyone will want to using an external program, no matter how glitzy.
- We must continue to improve the pure python version of Leo.
- The lure of web technology beckons.
- I'll continue to explore external hosts and their features. An atom or
vscode plugin may be next for me.
*Summary*
Plain Leo plugins (external gui plugins) should/must suffice to embed Leo
in atom, vscode, eclipse or jupyter. They may be easier to do than Leo's
console gui plugin!
Except for a few benign lines of code, Python's core will not change to
support external gui plugins.
Leo's core, markup (@others, section references, directives) and python
scripting are all part of Leo's essence. They will not change. And
neither will any other essential part of Leo that I haven't mentioned ;-)
Work will continue "forever" on improving the pure python version of Leo.
This may include work on all the cool features we envy in atom! This is
challenging work, even with access to the eric and pycharm code bases.
I will continue to explore options, including looking for nifty external
hosts. I would also like to do one external gui plugin as a learning
exercise.
Please keep your comments coming. Feel free to vote for the external gui
plugin you most want to see.
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.
