Re: LeoWapp plans

2018-11-03 Thread Matt Wilkie 

>
> Matt, I'm not sure how this will affect your distro work.  I do know that 
> the following pulls in a lot of packages:  conda install flexx -c 
> conda-forge
>

It looks pretty straightforward, but maybe I'll wait until we know if flexx 
is more than an experiment before adding it as a requirement. Pip is good 
at adding dependent packages on install, but it doesn't remove them when 
the master package is uninstalled.

Matt

-- 
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.

Re: LeoWapp plans

2018-11-02 Thread Terry Brown 
On Thu, 1 Nov 2018 20:41:48 -0700 (PDT)
Matt Wilkie  wrote:

> > I think "Flexx uses tornado" was a crossing of threads (ha ha ha),
> > I don't think it does. 
> 
> I know nothing about web sockets or the frameworks discussed in this 
> thread, but the docs say 
> 
> *"Flexx further depends on the following packages (all are pure
> Python, and the latter three are projects under the flexxui
> umbrella): Tornado, PScript,Webruntime,Dialite". *So yes it uses
> Tornado, but maybe not for sockets -- there is wording in 
> https://flexx.readthedocs.io/en/stable/app/api.html?highlight=tornado 
> indicating that while Tornado is required right now they're leaving
> the door open for different back ends in future.
> 
> Matt

Ah, good catch - I was aware of the other dependencies which are Flexx
offshoots, but overlooked Tornado.

If Flexx ends up with no role beyond passing messages between Leo and
Javascript, it would probably be better to just use Tornado or
something to do that.

Cheers -Terry

-- 
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.

Re: LeoWapp plans

2018-11-02 Thread Edward K. Ream 
On Thu, Nov 1, 2018 at 10:41 PM Matt Wilkie  wrote:

> I think "Flexx uses tornado" was a crossing of threads (ha ha ha), I
>> don't think it does.
>>
>
> I know nothing about web sockets or the frameworks discussed in this
> thread, but the docs say
>  *"Flexx
> further depends on the following packages (all are pure Python, and the
> latter three are projects under the flexxui umbrella): Tornado,
> PScript,Webruntime,Dialite". *So yes it uses Tornado, but maybe not for
> sockets -- there is wording in
> https://flexx.readthedocs.io/en/stable/app/api.html?highlight=tornado
> indicating that while Tornado is required right now they're leaving the
> door open for different back ends in future.
>

Matt, I'm not sure how this will affect your distro work.  I do know that
the following pulls in a lot of packages:  conda install flexx -c
conda-forge

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.

Re: LeoWapp plans

2018-11-01 Thread Matt Wilkie 

>
> I think "Flexx uses tornado" was a crossing of threads (ha ha ha), I 
> don't think it does. 
>

I know nothing about web sockets or the frameworks discussed in this 
thread, but the docs say 
 *"Flexx 
further depends on the following packages (all are pure Python, and the 
latter three are projects under the flexxui umbrella): Tornado, 
PScript,Webruntime,Dialite". *So yes it uses Tornado, but maybe not for 
sockets -- there is wording in 
https://flexx.readthedocs.io/en/stable/app/api.html?highlight=tornado 
indicating that while Tornado is required right now they're leaving the 
door open for different back ends in future.

Matt

-- 
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.

Re: LeoWapp plans

2018-11-01 Thread Edward K. Ream 
On Thursday, November 1, 2018 at 10:04:08 AM UTC-5, Edward K. Ream wrote:

With every step I take on this project, the goal seems to get closer faster 
> than expected.
>

I expect to complete the so-called skeleton in a day or three.  When that 
happens, devs will be able to prototype LeoWapp with their favorite 
framework.  They will use their framework to create Leo's javascript 
widgets. Starting with the skeleton, devs will fill in the details of 
communicating between python and javascript.  

To repeat, it's reasonable to experiment with multiple prototypes.  The 
skeleton will handle *everything* involving the interface with Leo's core. 
The skeleton will be in the devel branch. Devs should create separate git 
branches for individual prototypes.  I'll be creating a "flexx" branch when 
the skeleton is complete.

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.

Re: LeoWapp plans

2018-11-01 Thread Edward K. Ream 
On Thursday, November 1, 2018 at 5:53:39 AM UTC-5, Edward K. Ream wrote:

Rev 64742bc16 in dev demonstrates the main idea. 
>
> Starting Leo with `leo --gui=browser` successfully goes through Leo's 
> startup logic and calls BrowserGui.runMainLoop, which in turn runs all 
> Leo's unit tests and exits:
>
 
[snip] 
 

> This is mostly a fake, because BrowserGui is a subclass of NullGui, and 
> NullGui is designed to pass all unit tests.
>

Aha.  *The BrowserGui must use string widgets*, just like the NullGui 
does!  Indeed, there are no other widgets to use!  This means that (in a 
limited sense, see below) the BrowserGui really and truly *does *already 
pass all unit tests.

I'm dithering about whether the BrowserGui class should actually be a 
subclass of NullGui.  There are arguments to be made each way.  In any 
case, the BrowserGui must override all (or almost all) methods of the 
NullGui class, because in addition to updating the string widgets the 
BrowserGui must *also* pass on those changes to the javascript.

*Symmetry*

It's important to understand the *inherent *symmetry between the python and 
javascript sides.  When using the BrowserGui, all unit tests use the 
high-level api to "drive" the python code.  That's why all the unit tests 
pass, and should *continue* to pass when changes to the string widgets get 
passed on to the javascript widgets.

Similarly, when the javascript code changes the js widgets, those changes 
must be passed to python. From a *communication *standpoint, the situation 
is completely symmetric.  Changes to the python widgets get passed on to 
javascript, and vice versa.

The details of the communication need not be, and probably will not be, so 
symmetric.  The python widgets change as the result of calls to the 
high-level api, but the javascript code is free to "summarize" changes to 
the js widgets.

*Summary*

The BrowserGui class *already *implements string widgets. This suffices to 
have all unit tests pass now, and they should naturally *continue* to pass 
as work progresses.

The BrowserGui methods (for the high-level api) must also call their 
corresponding js methods (except during unit testing?)  to keep the js 
widgets in sync. Symmetrically, the javascript code must update the python 
string widgets when the js widgets change.

With every step I take on this project, the goal seems to get closer faster 
than expected.

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.

Re: LeoWapp plans

2018-11-01 Thread Edward K. Ream 
On Thu, Nov 1, 2018 at 5:53 AM Edward K. Ream wrote:

> The skeleton will provide explicit redirection methods for each and every
member of the high-level api...
> the BrowserGui class [will be] a subclass of LeoGui, not NullGui.  This
will force the BrowserGui class to implement all methods of the high-level
api that subclasses of LeoGui are required to implement.
>These methods will like all call something like bg.message(kind, *args,
**kwargs).

Not quite. What these methods do may depend on the framework.

Maybe in flex we can redirect to js using something that looks like python,
but the most general form of the calls will be: `bg.message(kind,
payload)`, where the exact form of the payload depends on the framework.

In any case, this is all the more reason to use a separate BrowserGui
method for each method of Leo's high-level api.

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.

Re: LeoWapp plans

2018-11-01 Thread Edward K. Ream 
On Wednesday, October 31, 2018 at 3:22:44 PM UTC-5, Edward K. Ream wrote:

This is close to my present plans, which is to create what might be called 
> a skeleton browser gui.
>

Rev 64742bc16 in dev demonstrates the main idea. 

Starting Leo with `leo --gui=browser` successfully goes through Leo's 
startup logic and calls BrowserGui.runMainLoop, which in turn runs all 
Leo's unit tests and exits:

def runMainLoop(self, fileName=None):
'''The main loop for the browser gui.'''
if fileName:
print('LeoWapp running: %s...' % g.shortFileName(fileName))
else:
print('LeoWapp running...')
if 1: # Run all unit tests.
path = g.os_path_finalize_join(
g.app.loadDir, '..', 'test', 'unittest.leo')
c = g.openWithFileName(path, gui=self)
c.findCommands.ftm = g.NullObject()
# A hack. Maybe the NullGui should do this.
c.debugCommands.runAllUnitTestsLocally()
print('calling sys.exit(0)')

sys.exit(0)

This is mostly a fake, because BrowserGui is a subclass of NullGui, and 
NullGui is designed to pass all unit tests.

But still, the work so far will likely be the *only* changes to Leo's 
core.  As expected, they have been minimal.

*Next Phase*

At present, the BrowserGui class contains a __getattr__ method, but in fact 
this wasn't needed and actually complicated subclassing BrowserGui from 
NullGui.

bg.__getattr__ is:

def __getattr__ (self, attr):
'''Handle an missing attribute.'''
if attr in (
'frameFactory',
'set_minibuffer_label',
):
# These are optional ivars.
raise AttributeError
# Simulate the handling of the function call.
return self.message(attr)

The idea is that bg.message is a stand in for code that would redirect 
calls to javascript.

However, when I wrote this I realized that there doesn't seem to be a way 
make those calls with any arguments.  Perhaps there is a clever way.  But 
it doesn't matter. Imo, __getattr__ is usually too clever by half, and this 
is no exception.

Instead, the skeleton will provide explicit redirection methods for each 
and every member of the high-level api.  This brute force approach will 
simplify debugging, which __getattr__ *always* complicates.

*Summary*

Work so far has gone *exactly* as expected. To do:

- Make the BrowserGui class a subclass of LeoGui, not NullGui.  This will 
force the BrowserGui class to implement all methods of the high-level api 
that subclasses of LeoGui are required to implement.

- These methods will like all call something like bg.message(kind, *args, 
**kwargs).

- bg.message is supposed to pass messages to the js framework, whatever it 
is.

Until bg.message becomes functional, most gui-related unit tests should 
fail.  That's actually progress.

I expect to complete the skeleton today.  At that point, anyone should be 
able to use the skeleton on whatever gui framework they like.  If you are 
interested in doing so, please do your work in a separate git branch.

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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 
On Wed, Oct 31, 2018 at 11:27 AM Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> I would try something like this for a minimal prototype:
>
>- Express a minimal Leo tree (with clones) as a Inspire Tree (yes I
>know I have chosen a particular tech for interface).
>- See how can I send changes to the Inspire Tree from a web interface
>(maybe using events).
>- Translate back those changes to Leo.
>- Abstract that from a particular WUI (Web User Interface) so the
>first point is not a must.
>
> That would give me a sense of what needs to be done, abstracted and
> understood, so a Leo server can bring outlining services to a web interface.
>
This is close to my present plans, which is to create what might be called
a skeleton browser gui.

Starting there, I'll probably make a flexx prototype.  I would encourage
you to make a quick prototype for Inspire, and perhaps Vitalije would want
to do the same for Tornado.

I'd like to have the skeleton ready in a day or so.  It will be in
leowapp.py.

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.

Re: LeoWapp plans

2018-10-31 Thread Offray Vladimir Luna Cárdenas 
Hi,

I would try something like this for a minimal prototype:

  * Express a minimal Leo tree (with clones) as a Inspire Tree (yes I
know I have chosen a particular tech for interface).
  * See how can I send changes to the Inspire Tree from a web interface
(maybe using events).
  * Translate back those changes to Leo.
  * Abstract that from a particular WUI (Web User Interface) so the
first point is not a must.

That would give me a sense of what needs to be done, abstracted and
understood, so a Leo server can bring outlining services to a web interface.

Cheers,

Offray

On 10/31/18 10:01 AM, Edward K. Ream wrote:
> On Wednesday, October 31, 2018 at 9:28:02 AM UTC-5, Terry Brown wrote:
>
> I mentioned this elsewhere, but just want to say Flexx is
> different in
> that it translates Python to javascript, although not really, really
> it lets you write javascript using Python syntax.  So its intent is
> that you don't write javascript, and if you do it that way, you
> probably won't be able to swap out frameworks easily.
>
>
> My plan is to have the browser gui translate all calls to Leo's
> high-level-api into messages sent to javascript. This part is likely
> to be very similar, and very simple, regardless of the chosen framework.
>
> Yes, the javascript that receives these calls (and that generates
> events) is going to be different, maybe very different, depending on
> the framework.
>
> My plan is to avoid trying to understand all the details initially. 
> We may indeed find difficulties, even gotchas. But they will be found
> only after writing code.
>  
>
> Flexx's expected model for communication between the Python and
> javascript sides is perhaps less swap out able. You could just use it
> as a message pipeline, but there are probably other options for that.
>
>
> This is one of my concerns as well.
>
> And I'd expect this project to be significantly bigger than the
> curses project.
>
>
> I'll stick to my initial estimate.  The npyscreen library was way
> beyond difficult. It probably wasn't apparent to anyone but me how
> much work I did on the curses gui, and how little we all got for all
> that work.
>
> Unless there are whole areas of the browser gui that I don't
> understand (possible), creating browser widgets and handling browser
> events is going to be /much /easier than with npyscreen no matter what
> framework we eventually end up using.
>
> One more thing. The prototype needs only the most simplistic of
> widgets.  Yesterday I ripped out the html code from leowapp.py, but
> that code still exists.  It defines 4 text areas, for the tree, body,
> log and minibuffer.  We can go a long way (using any framework) with
> similar prototype widgets.
>
> *Summary*
>
> Thanks, Terry, for these comments.  They help to clarify the issues.
>
> I expect to write a bare-bones prototype in a day or three.  I had to
> invent a listener scheme to make debugging npyscreen feasible.  That
> took almost a week, iirc. In contrast, all major browsers have
> sophisticated debuggers.
>
> 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.

-- 
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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 
On Wed, Oct 31, 2018 at 10:17 AM vitalije  wrote:

For websocket to work there must be some thread which would check socket
> and call appropriate methods/functions when websocket has been open,
> closed, or new message has arrived. This thread should also take your
> outgoing messages and send them to the browser. Tornado has built in IOLoop
> which handles all threads and user doesn't have to do anything about
> threads except to call IOLoop.start once. This is very similar like
> starting gui application by starting mainloop.
>
> In essence web-socket programming is then very much like GUI programming.
> You define methods that will be called when connection is established (at
> that time one usually stores the sender address for later communication);
> then on each received message (which is just an object of bytes type), you
> need to decode this message (for example json.loads(msg)), and depending on
> decoded message content perform appropriate action. This action may be to
> reply with some value that browser has asked for, or to change something in
> Leo outline, or to execute script and return result. For events that are
> generated inside Leo (for example when outline needs to be redrawn)
> websocket handler should send a message to browser informing about changes.
>

Thanks for all these details.  They are interesting. I had such details in
mind when I wrote that one would have to implement events using just
websockets.  Perhaps Tornado does some of the work.

I've just added Tornado to the list of frameworks to study. I didn't know
it is written in Python.  PyZMQ is a wrapper around 0MQ, which is a native
lib.  Installing 0MQ is non-trivial, but that Anaconda includes it.

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.

Re: LeoWapp plans

2018-10-31 Thread Terry Brown 
I think "Flexx uses tornado" was a crossing of threads (ha ha ha), I
don't think it does.

Flexx completely hides the websockets part, it's more like React (I
think, having used that once), but basically signals / listeners /
actions / reactions. It actually takes a while to understand what part
of the code's running in JS and what part in Python, seeing it's all
authored in Python.  Then you run into things like "%06x" % n not
converting n to a hex string on the JS side.  But overall the
translation from core Python to JS is quite impressive, as in so
transparent you don't even notice it.

Cheers -Terry

On Wed, Oct 31, 2018 at 10:17 AM vitalije  wrote:
>>
>> Does that mean you think the flexx framework is a good idea? Or do you mean 
>> that Tornado itself would be the framework?
>
>
> I don't know about flexx. But you wrote above that flexx uses tornado for 
> websockets. I conclude from that tornado is lower level than flexx. And I 
> have implemented some websocket using tornado and it seems to me that it can 
> achieve on its own what you need for LeoWapp.
>
> For websocket to work there must be some thread which would check socket and 
> call appropriate methods/functions when websocket has been open, closed, or 
> new message has arrived. This thread should also take your outgoing messages 
> and send them to the browser. Tornado has built in IOLoop which handles all 
> threads and user doesn't have to do anything about threads except to call 
> IOLoop.start once. This is very similar like starting gui application by 
> starting mainloop.
>
> In essence web-socket programming is then very much like GUI programming. You 
> define methods that will be called when connection is established (at that 
> time one usually stores the sender address for later communication); then on 
> each received message (which is just an object of bytes type), you need to 
> decode this message (for example json.loads(msg)), and depending on decoded 
> message content perform appropriate action. This action may be to reply with 
> some value that browser has asked for, or to change something in Leo outline, 
> or to execute script and return result. For events that are generated inside 
> Leo (for example when outline needs to be redrawn) websocket handler should 
> send a message to browser informing about changes.
>
> Vitalije
>
> --
> 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.

-- 
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.

Re: LeoWapp plans

2018-10-31 Thread vitalije 

>
> Does that mean you think the flexx framework is a good idea? Or do you 
> mean that Tornado itself would be the framework?
>

I don't know about flexx. But you wrote above that flexx uses tornado for 
websockets. I conclude from that tornado is lower level than flexx. And I 
have implemented some websocket using tornado and it seems to me that it 
can achieve on its own what you need for LeoWapp.

For websocket to work there must be some thread which would check socket 
and call appropriate methods/functions when websocket has been open, 
closed, or new message has arrived. This thread should also take your 
outgoing messages and send them to the browser. Tornado has built in IOLoop 
which handles all threads and user doesn't have to do anything about 
threads except to call IOLoop.start once. This is very similar like 
starting gui application by starting mainloop. 

In essence web-socket programming is then very much like GUI programming. 
You define methods that will be called when connection is established (at 
that time one usually stores the sender address for later communication); 
then on each received message (which is just an object of bytes type), you 
need to decode this message (for example json.loads(msg)), and depending on 
decoded message content perform appropriate action. This action may be to 
reply with some value that browser has asked for, or to change something in 
Leo outline, or to execute script and return result. For events that are 
generated inside Leo (for example when outline needs to be redrawn) 
websocket handler should send a message to browser informing about changes.

Vitalije

-- 
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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 
On Wednesday, October 31, 2018 at 9:28:02 AM UTC-5, Terry Brown wrote:

I mentioned this elsewhere, but just want to say Flexx is different in 
> that it translates Python to javascript, although not really, really 
> it lets you write javascript using Python syntax.  So its intent is 
> that you don't write javascript, and if you do it that way, you 
> probably won't be able to swap out frameworks easily.


My plan is to have the browser gui translate all calls to Leo's 
high-level-api into messages sent to javascript. This part is likely to be 
very similar, and very simple, regardless of the chosen framework.

Yes, the javascript that receives these calls (and that generates events) 
is going to be different, maybe very different, depending on the framework.

My plan is to avoid trying to understand all the details initially.  We may 
indeed find difficulties, even gotchas. But they will be found only after 
writing code. 
 

> Flexx's expected model for communication between the Python and 
> javascript sides is perhaps less swap out able. You could just use it 
> as a message pipeline, but there are probably other options for that. 
>

This is one of my concerns as well. 

And I'd expect this project to be significantly bigger than the curses 
> project. 
>

I'll stick to my initial estimate.  The npyscreen library was way beyond 
difficult. It probably wasn't apparent to anyone but me how much work I did 
on the curses gui, and how little we all got for all that work.

Unless there are whole areas of the browser gui that I don't understand 
(possible), creating browser widgets and handling browser events is going 
to be *much *easier than with npyscreen no matter what framework we 
eventually end up using.

One more thing. The prototype needs only the most simplistic of widgets.  
Yesterday I ripped out the html code from leowapp.py, but that code still 
exists.  It defines 4 text areas, for the tree, body, log and minibuffer.  
We can go a long way (using any framework) with similar prototype widgets.

*Summary*

Thanks, Terry, for these comments.  They help to clarify the issues.

I expect to write a bare-bones prototype in a day or three.  I had to 
invent a listener scheme to make debugging npyscreen feasible.  That took 
almost a week, iirc. In contrast, all major browsers have sophisticated 
debuggers.

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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 

On Wednesday, October 31, 2018 at 9:30:37 AM UTC-5, Edward K. Ream wrote:

The first version of the script hard-coded the path to unittest.leo:

c = controller.openLeoFile(r'c:\leo.repo\leo-editor\leo\test\unittest.leo')

However, we can use the bridge's g.app.loadDir to generalize the code:

path = g.os_path_finalize_join(
g.app.loadDir, '..', 'test', 'unittest.leo')
c = controller.openLeoFile(path)

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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 
On Wednesday, October 31, 2018 at 5:32:33 AM UTC-5, Edward K. Ream wrote:

2. Create a hack that runs all unit tests.  I expect all gui-related tests 
> to fail.
>

Leo's own --script logic is byzantine.  It's simpler just to run the 
following test file from python itself:

import leo.core.leoBridge as leoBridge

controller = leoBridge.controller(
gui='nullGui',
loadPlugins=False,
readSettings=False,
silent=False,
verbose=True,
)
g = controller.globals()
c = controller.openLeoFile(r'c:\leo.repo\leo-editor\leo\test\unittest.leo')
assert c
p = g.findTopLevelNode(c, 'Active Unit Tests')
assert p
c.selectPosition(p)
c.testManager.doTests()

This runs the the tests with the null gui, which uses python strings to 
simulate widgets.  The results are:

Ran 909 tests in 20.533s

FAILED (failures=9, errors=1, skipped=32)

So a few tests should be changed or skipped to make everything pass.

The first version of the browser gui will be a copy of the null gui, so 
everything will pass at first with the browser gui.  I'll then start 
replacing the string-based code, at which point many more tests will fail.

I expect to get this done today.

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.

Re: LeoWapp plans

2018-10-31 Thread Terry Brown 
I mentioned this elsewhere, but just want to say Flexx is different in
that it translates Python to javascript, although not really, really
it lets you write javascript using Python syntax.  So its intent is
that you don't write javascript, and if you do it that way, you
probably won't be able to swap out frameworks easily. OTOH there's
always a point where you're committed to a framework - an interface
written in React or Vue is like an interface written in Qt.  But
Flexx's expected model for communication between the Python and
javascript sides is perhaps less swap out able. You could just use it
as a message pipeline, but there are probably other options for that.

And I'd expect this project to be significantly bigger than the curses project.

Cheers -Terry

On Wed, Oct 31, 2018 at 5:44 AM Edward K. Ream  wrote:
>
> On Wednesday, October 31, 2018 at 5:32:33 AM UTC-5, Edward K. Ream wrote:
>
>> flexx looks like exactly what LeoWapp needs, but I won't commit to flexx 
>> until much later, if at all.
>
>
> I forgot to mention two things:
>
> 1. Studying vue.js is high on my list.  An important goal of LeoWapp is to 
> support Joe Orr's work.
>
> 2. LeoWapp will undoubtedly be significantly easier than Leo console gui.  My 
> goal is to have unit tests fail in a day or two.
>
> 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.

-- 
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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 
On Wed, Oct 31, 2018 at 6:05 AM vitalije  wrote:

> I was thinking to suggest tornado but there were already lots of
> suggestions, so I decided rather not to.
>

Your timing is spot on.  Earlier I would not have been able to handle more
suggestions.

>
> Tornado has websockets integrated and it is quite easy to use them.
> Tornado supported until recently Python 2.7 and earlier versions of Python
> 3. So it used to have some back-ported functions like async and await which
> are available in Python 3.6. AFAIK tornado is switching toward this native
> async/await concepts of new Python >= 3.6. They are essential for
> web-sockets and using built in async/await greatly simplifies code.
>

Thanks for this.

What I am trying to say is that if you are using tornado for web-sockets
> that would suffice. Tornado can do AJAX as well as serving HTML,
> JavaScript, CSS and everything else.
>

Does that mean you think the flexx framework is a good idea? Or do you mean
that Tornado itself would be the framework?

I've been forgetting to say something about websockets.  There may be
problems with frameworks, but there would be bigger problems with using raw
websockets.  One would have to create event handling (and events) from
scratch, including the notion of idle time.

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.

Re: LeoWapp plans

2018-10-31 Thread vitalije 
I was thinking to suggest tornado but there were already lots of 
suggestions, so I decided rather not to.

Tornado has websockets integrated and it is quite easy to use them. Tornado 
supported until recently Python 2.7 and earlier versions of Python 3. So it 
used to have some back-ported functions like async and await which are 
available in Python 3.6. AFAIK tornado is switching toward this native 
async/await concepts of new Python >= 3.6. They are essential for 
web-sockets and using built in async/await greatly simplifies code. 

What I am trying to say is that if you are using tornado for web-sockets 
that would suffice. Tornado can do AJAX as well as serving HTML, 
JavaScript, CSS and everything else.

Vitalije

-- 
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.

Re: LeoWapp plans

2018-10-31 Thread Edward K. Ream 
On Wednesday, October 31, 2018 at 5:32:33 AM UTC-5, Edward K. Ream wrote:

flexx looks like exactly what LeoWapp needs, but I won't commit to flexx 
> until much later, if at all.
>

I forgot to mention two things:

1. Studying vue.js is high on my list.  An important goal of LeoWapp is to 
support Joe Orr's work.

2. LeoWapp will undoubtedly be significantly easier than Leo console gui.  
My goal is to have unit tests fail in a day or two.

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.