You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Everything I see suggests that flexx is exactly the right tool for LeoWapp: Leo's browser gui:
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 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 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.
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 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
Translating a python 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.
The learning curve is easy. For example, %10s doesn't justify text inside an event handler:
# ev is a flexx event.id_=ev.source.titleorev.source.texttext='%10s: %s'% (id_, kind+ev.type)
The reason: text is a JS (flexx javascript string), not a python string.
PScript should be as flexible as javascript for our purposes. PScript almost certainly can support flexx widgets without any problem.
Creating and laying out flexx widgets is much simpler than with Qt or npyscreen.
Look at the flexx demos. Using nested "with" statements to lay out pages is clever.
There are many ways to launch flexx prototypes.
The Ways to run a Flexx app 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.
I use this flexx.bat file to run the leo/plugins/leoflexx.py prototype:
if__name__=='__main__':
# Use `--flexx-webruntime=browser` to run in browser.flx.launch(TreeExample)
flx.run()
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. Either way, debugging will be much easier than debugging the console gui code.
Flexx provides essential wrappers for Tornado.
I have not studied the Tornado docs, but it seems likely that flexx adds substantially to Tornado. Tornado might be more flexible for some purposes, but flexx seems exactly what is needed for LeoWapp.
The text was updated successfully, but these errors were encountered:
Everything I see suggests that flexx is exactly the right tool for LeoWapp: Leo's browser gui:
Imo, this symmetry is essential, and flexx achieves this symmetry far more thoroughly than I would have thought possible. flexx uses 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 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.
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 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
Translating a python 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.
The learning curve is easy. For example,
%10s
doesn't justify text inside an event handler:The reason: text is a JS (flexx javascript string), not a python string.
PScript should be as flexible as javascript for our purposes. PScript almost certainly can support flexx widgets without any problem.
Look at the flexx demos. Using nested "with" statements to lay out pages is clever.
The Ways to run a Flexx app 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.
I use this flexx.bat file to run the leo/plugins/leoflexx.py prototype:
Within leoflexx.py, the following code appears:
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. Either way, debugging will be much easier than debugging the console gui code.
I have not studied the Tornado docs, but it seems likely that flexx adds substantially to Tornado. Tornado might be more flexible for some purposes, but flexx seems exactly what is needed for LeoWapp.
The text was updated successfully, but these errors were encountered: