On Sat, Nov 3, 2018 at 3:21 PM Terry Brown wrote: Flexx is very different from other frame works because you write everything > in Python. You might try writing a web gui in Vue, React, or JQuery to get > something more typical. >
Thanks for this. I am becoming convinced that flexx is exactly what Leo needs. This response will be pre-writing for the info item #1011 <https://github.com/leo-editor/leo-editor/issues/1011>: About Leo and flexx. Btw, I agree that LeoWapp will be a major project. It may turn out to be more work than the console gui project because: - LeoWapp is so much more important than the console gui. - flexx (or whatever) is so much more capable than npyscreen. - There are hosting issues that do not arise when using the console gui. I spent yesterday skimming through the flexx manuals and trying example code, including various ways of launching prototypes. Everything I see suggests that flexx is *exactly* the right tool for Leo's browser gui: 1. Flexx is almost completely symmetric with regard to both communication and classes. Imo, this symmetry is essential, and flexx achieves this symmetry far more thoroughly than I would have thought possible. flexx uses virtually identical proxies on both ends. As a result, the corresponding python and js classes are almost identical. You can see this in the Sensible Usage Patterns <https://flexx.readthedocs.io/en/stable/guide/patterns.html> page of the flexx docs. Hardly any changes are required to "lean" towards js or python. This is remarkable. Aside: I'm not sure which way Leo's flexx gui will lean. 2. Flexx solves the circular events problem elegantly. Leo's Qt gui must have lockouts so that Qt events don't spawn endless chains of events. In contrast, flexx solves this problem elegantly. See the diagram in the middle of the Events System <https://flexx.readthedocs.io/en/stable/guide/event_system.html> page. Immediately below this diagram is the following: QQQ One might argue that the information flow is still circular, because there is an arrow going from reactions to actions. This is true, but note that actions invoked from reactions are not directly executed; they are pended and will be executed only after all reactions are done. QQQ 3. PScript <https://flexx.readthedocs.io/en/stable/guide/pscript_modules_scope.html>is exactly what I want. The translation of a python-like dialect to javascript cuts the Gordian Knot of lack of support for python in browser. PScript is a separate project, which appears to be under active development. It is already miles ahead of my fondest dreams. Yes, there is a learning curve, but it's not difficult. For example, it took me awhile to see why %10s doesn't justify text inside an event handler, where ev is a flexx event: id_ = ev.source.title or ev.source.text text = '%10s: %s' % (id_, kind + ev.type) The answer: text is a JS (flexx javascript string), not a python string. One could worry that somehow PScript won't be as flexible as javascript, but that seems unlikely. We only care about the combination of PScript and flexx's Widgets, and it's hard to imagine that PScript can't service flexx's needs adequately. 4. Creating and laying out flexx widgets is so much simpler than with Qt or npyscreen. Look at the flexx demos <https://flexx.readthedocs.io/en/stable/examples/index.html#demos>. Using nested "with" statements to lay out pages is clever. 5. There are many ways to launch flexx prototypes. The Ways to run a Flexx app <https://flexx.readthedocs.io/en/stable/guide/running.html> page covers the basics. I like to fire up the browser during development. This can be done with the --flexx-webruntime=browser option. See the configuration page <https://flexx.readthedocs.io/en/stable/configuration.html>. I use this flexx.bat file to run the leo/plugins/leoflexx.py prototype. (not pushed yet): python leo\plugins\leoflexx.py --flexx-webruntime=browser Within leoflexx.py, the following code appears: if __name__ == '__main__': # Use `--flexx-webruntime=browser` to run in browser. flx.launch(TreeExample) flx.run() 6. Flexx has a great in-browser debugger. When run from flexx, F12 brings up a flexx-oriented debugger. This is not the same as Mozilla's debugger, which can be brought up with Shift-Ctrl-C. I have little experience debugging js, but there is no doubt that either debugger is a lot more capable than the print statements I had to use when debugging the console gui. 7. Flexx provides essential wrappers for Tornado. I have not studied the Tornado docs <http://www.tornadoweb.org/en/stable/> at all, so this is a provisional conclusion. However, it seems unlikely that flexx would exist if using Tornado were as easy as using flexx. Oh, I suppose one can image a situation in which using "raw" Tornado would give some extra flexibility, but for now flexx seems to give exactly the services that LeoWapp needs. Furthermore, flexx's source code is small and elegant. There is a flexx.leo study outline here <https://github.com/leo-editor/leo-editor-contrib/tree/devel/StudyOutlines>. *Summary* Everything I know suggests that flexx is a perfect fit for LeoWapp. However, these are early days, and I may be ignorant of something essential. All comments 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 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.
