Re: Could Leo Have Canvas-type Nodes?

[tbp1...@gmail.com]

On Tuesday, March 22, 2022 at 10:29:41 AM UTC-4 Edward K. Ream wrote:

>
> On Tue, Mar 22, 2022 at 9:17 AM tbp1...@gmail.com 
>   > wrote:
> As a proof of principle, I have already adapted VR3 to run in  tab.  It 
> didn't take many changes.
>
 

> I see.  If this is the extent of the idea, I don't see a problem.  Why is 
> a tab superior to a separate VR pane?
>

This would be only part of the picture.  And having the body pane as a tab 
in the log pane isn't an essential part of this idea.  It just shows that 
the tab-making machinery of the log pane could work basically unchanged in 
place of the current body pane.  The rest of the idea is the addition of 
new objects to nodes, such a c.canvas, that could contain data or perhaps 
to be rendered, graphed, or otherwise displayed.

Displaying a rendering in a tabbed pane instead of a separate VR pane has 
the benefit of more screen viewing area, which is annoying lacking when the 
Leo window is split up into three panes - unless you have a large hi-res 
monitor or multiple monitors.  In addition, tabbed panes would probably be 
better when you have several different kinds of rendering and image display 
to do.  For example, it's tricky swapping a Matplotlib Qt canvas in and out 
all the time, and there are probably memory leaks involved each time.  If a 
tab always held a Qy canvas for Matplotlib, then it wouldn't have to be 
swapped when one wanted to render a Markdown page, for example.

For example, my mindmap script writes the svg for a mindmap to a node then 
selects that node so that vr3 will render it.  There isn't currently a way 
to send the svg directly to vr3 except by putting it into a node.  If it 
could be written to c.canvas of the current node, then vr3 could pick it up 
from there, no need to create an additional node or a temporary file (the 
main other way that VR/VR3 gets data to render).  This could be simulated 
by copying the svg to the clipboard and getting vr3 to plot from the 
clipboard.  But that technique is limited to markup like svg.  If we had a 
c.canvas, all kinds of things could be put there, including perhaps binary 
data.  

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/54271620-730a-45f7-9d7d-f3b588641637n%40googlegroups.com.

Re: Could Leo Have Canvas-type Nodes?

[Edward K. Ream]

On Tue, Mar 22, 2022 at 9:24 AM tbp1...@gmail.com 
wrote:

> Good Lord, we've already got it!  You can open a body editor in the tabbed
> log pane from the splitter right-click menu.  Then you can make the whole
> log pane into a full-height panel.  So now we can already have both VR3
> (well, my non-plugin tab version is currently named "VR4") and the body in
> tabs, so we can check out if we really like it or not.  It gives a lot more
> screen space for viewing than using the triple panes we currently use be
> default.
>

OK then.  I'll leave you two to 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2qJwGG%3DTYH%2BdDRYmLB81XRyM5Vxg-eaeaGK%2BYKowQ_jA%40mail.gmail.com.

Re: Could Leo Have Canvas-type Nodes?

[Edward K. Ream]

On Tue, Mar 22, 2022 at 9:17 AM tbp1...@gmail.com 
wrote:

> As a proof of principle, I have already adapted VR3 to run in  tab.  It
> didn't take many changes.
>

I see.  If this is the extent of the idea, I don't see a problem.  Why is a
tab superior to a separate VR pane?

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS1Qup%2BKh_RRkuh-fBTy5ZknhKRcoC5szd5PYqABoAoCiw%40mail.gmail.com.

Re: Could Leo Have Canvas-type Nodes?

[Edward K. Ream]

On Mon, Mar 21, 2022 at 9:45 AM Jacob Peck  wrote:

> While I anticipate pushback on this idea, I am wholeheartedly for it.  I
> have long wanted such a feature, but couldn't figure out just how to word
> it.
>

Imo, the pushback is justified, for several reasons:

1. Leo's VR and VR3 plugins are superior to the proposal. In the present
world, the body pane contains a text representation of the desired
graphics.  The VR pane shows the result.

2. Leo's VR and VR3 plugins are superior to the Jupyter way, which is quite
clumsy. One has to toggle between various views of the data.

Please don't ask me to change my mind :-)  Oh, I might accept a plugin that
does what is wanted, but don't count on 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS0JR963KGSH%3D_MBX9CuZU0zPMBM3UtW66%2B1P2UHDLOqhQ%40mail.gmail.com.

Re: Could Leo Have Canvas-type Nodes?

[tbp1...@gmail.com]

Good Lord, we've already got it!  You can open a body editor in the tabbed 
log pane from the splitter right-click menu.  Then you can make the whole 
log pane into a full-height panel.  So now we can already have both VR3 
(well, my non-plugin tab version is currently named "VR4") and the body in 
tabs, so we can check out if we really like it or not.  It gives a lot more 
screen space for viewing than using the triple panes we currently use be 
default.

On Tuesday, March 22, 2022 at 10:17:20 AM UTC-4 tbp1...@gmail.com wrote:

> As a proof of principle, I have already adapted VR3 to run in  tab.  It 
> didn't take many changes.
>
> On Tuesday, March 22, 2022 at 8:58:59 AM UTC-4 gates...@gmail.com wrote:
>
>> I wrote the nodetags.py plugin, and a few others that use new log-pane 
>> tabs (nodewatch, the terribly broken interactive python terminal plugin, 
>> etc.) :)
>>
>> Tabs are great.  I've long wished that the body pane was tabbed -- 
>> would've made one of my personal "Leo Apps" much easier to implement.
>>
>> On Tue, Mar 22, 2022 at 7:51 AM tbp1...@gmail.com  
>> wrote:
>>
>>>
>>> Let's start with the Log pane.  Whoever came up with it had a brilliant 
>>> idea. Most users are probably familiar with the Find and Nav tabs, and 
>>> possibly the Completion and Spell tabs.  You click on a tab and get a 
>>> completely different view.  What you may not realize is that a tab is just 
>>> the display device for an entire mini-application, in the form of scripts 
>>> and a set of one or more "widgets".  To hook it into the log pane with its 
>>> own tab is remarkably simple, programming-wise - this is the brilliant 
>>> part.  You just give the top-level widget and a tab name to the log pane 
>>> and the pane sets up all the tab and switching machinery for you.  So a tab 
>>> could contain almost anything - a web browser, a dictionary, you name it.  
>>> If it has a single top-level display widget and code behind that, it can 
>>> get its own tab in the log pane.  The scripts for the tab have access to 
>>> all of Leo's code and data, so they can do just about whatever they like.  
>>> Tabs can be installed by plugins, bit also by non-plugin scripts.
>>>
>>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b481cde3-2739-48ef-90c0-c69eea0f4632n%40googlegroups.com.

Re: Could Leo Have Canvas-type Nodes?

[tbp1...@gmail.com]

As a proof of principle, I have already adapted VR3 to run in  tab.  It 
didn't take many changes.

On Tuesday, March 22, 2022 at 8:58:59 AM UTC-4 gates...@gmail.com wrote:

> I wrote the nodetags.py plugin, and a few others that use new log-pane 
> tabs (nodewatch, the terribly broken interactive python terminal plugin, 
> etc.) :)
>
> Tabs are great.  I've long wished that the body pane was tabbed -- 
> would've made one of my personal "Leo Apps" much easier to implement.
>
> On Tue, Mar 22, 2022 at 7:51 AM tbp1...@gmail.com  
> wrote:
>
>>
>> Let's start with the Log pane.  Whoever came up with it had a brilliant 
>> idea. Most users are probably familiar with the Find and Nav tabs, and 
>> possibly the Completion and Spell tabs.  You click on a tab and get a 
>> completely different view.  What you may not realize is that a tab is just 
>> the display device for an entire mini-application, in the form of scripts 
>> and a set of one or more "widgets".  To hook it into the log pane with its 
>> own tab is remarkably simple, programming-wise - this is the brilliant 
>> part.  You just give the top-level widget and a tab name to the log pane 
>> and the pane sets up all the tab and switching machinery for you.  So a tab 
>> could contain almost anything - a web browser, a dictionary, you name it.  
>> If it has a single top-level display widget and code behind that, it can 
>> get its own tab in the log pane.  The scripts for the tab have access to 
>> all of Leo's code and data, so they can do just about whatever they like.  
>> Tabs can be installed by plugins, bit also by non-plugin scripts.
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4d869fd3-11d0-4dca-9c93-f720d6e4844dn%40googlegroups.com.

Re: Could Leo Have Canvas-type Nodes?

[Jacob Peck]

I wrote the nodetags.py plugin, and a few others that use new log-pane tabs
(nodewatch, the terribly broken interactive python terminal plugin, etc.) :)

Tabs are great.  I've long wished that the body pane was tabbed -- would've
made one of my personal "Leo Apps" much easier to implement.

On Tue, Mar 22, 2022 at 7:51 AM tbp1...@gmail.com 
wrote:

>
> Let's start with the Log pane.  Whoever came up with it had a brilliant
> idea. Most users are probably familiar with the Find and Nav tabs, and
> possibly the Completion and Spell tabs.  You click on a tab and get a
> completely different view.  What you may not realize is that a tab is just
> the display device for an entire mini-application, in the form of scripts
> and a set of one or more "widgets".  To hook it into the log pane with its
> own tab is remarkably simple, programming-wise - this is the brilliant
> part.  You just give the top-level widget and a tab name to the log pane
> and the pane sets up all the tab and switching machinery for you.  So a tab
> could contain almost anything - a web browser, a dictionary, you name it.
> If it has a single top-level display widget and code behind that, it can
> get its own tab in the log pane.  The scripts for the tab have access to
> all of Leo's code and data, so they can do just about whatever they like.
> Tabs can be installed by plugins, bit also by non-plugin scripts.
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJ1i%2BSYP-NxVEQ1Snuv%3D24Mywo07ZMcyHjdQBjkmYCPT2%3DsT%3DQ%40mail.gmail.com.

Re: Could Leo Have Canvas-type Nodes?

[tbp1...@gmail.com]

Picking up the theme of my previous post, how would things work from a 
user's point of view?  There could be several types of tabs.  One would be 
a tab to render - visualize - the selected body or subtree, the way that 
the viewrendered and viewrendered3 plugins do now.  Think of VR3 in a 
tabbed pane instead of in its own separate pane as it is now.  This solves 
most of of the problems with the current VR3.  The biggest problem is that 
VR3 updates every few keystrokes.  That is OK for small bodies, but for 
larger ones or subtrees, the typing and refresh become slower and more 
balky.  (VR3 has a "freeze" mode where it updates only when told to).As a 
tabbed pane, it would only have to update when the user tabs to it, so 
there would be no interference with typing and no visual distraction as the 
rendering display flashes and changes..  I find it rare that I need to 
watch the VR3 pane live while I'm typing.  Mostly I want to type something 
and then make sure it renders as I intended.  Or I want to run some code 
and see the result - again, not really a live view while typing.

So the current VR/VR3 plugins could be adapted to display in one of the 
tabs.  Now about having a drawing canvas.  Let's take Matplotlib as a 
starting point.  You can use it by writing code that asks it to display 
data, usually as graphs or charts.  You can put that code into a Leo node 
and execute it, possibly with CTRL-B.  By default, Matplotlib opens up its 
own independent window and draws to that, with its own interactive 
controls.  But Matplotlib has other canvas possibilities.  These include a 
Qt canvas widget, and the @pyplot nodes make use of that.  It was a 
brilliant move by whoever came up with it, to replace the default 
Matplotlib canvas by a Qt widget in the VR pane. (I don't have that working 
in VR3 for a number of technical reasons I won't get into here).  

That idea could be used in another of our new tabs.  Any code that would 
normally produce a Matplotlib display, not just pyplot but, for example, 
plotnine or (I'm fairly sure) Holoview, would be able to write to the tab 
instead.  And presumably any code that can use a Qt canvas could write to 
one of these tabs.

On Tuesday, March 22, 2022 at 7:51:28 AM UTC-4 tbp1...@gmail.com wrote:

> I'm getting very enthusiastic about this notion because I can see how it 
> could work - from  user interface, architectural, and implementation points 
> of view.  Of course, the devil is in the details and I'm only looking at an 
> overall picture.  It seems to me that a small change in Leo's design would 
> open up all kinds of possibilities.  My thinking is guided by a number of 
> features that already exist, especially 1) the tabbed Log pane; 2) the 
> machinery behind the display of @pyplot nodes, and 3) the viewrendered and 
> viewrendered3 plugins.
>
> Let's start with the Log pane.  Whoever came up with it had a brilliant 
> idea. Most users are probably familiar with the Find and Nav tabs, and 
> possibly the Completion and Spell tabs.  You click on a tab and get a 
> completely different view.  What you may not realize is that a tab is just 
> the display device for an entire mini-application, in the form of scripts 
> and a set of one or more "widgets".  To hook it into the log pane with its 
> own tab is remarkably simple, programming-wise - this is the brilliant 
> part.  You just give the top-level widget and a tab name to the log pane 
> and the pane sets up all the tab and switching machinery for you.  So a tab 
> could contain almost anything - a web browser, a dictionary, you name it.  
> If it has a single top-level display widget and code behind that, it can 
> get its own tab in the log pane.  The scripts for the tab have access to 
> all of Leo's code and data, so they can do just about whatever they like.  
> Tabs can be installed by plugins, bit also by non-plugin scripts.
>
> So this is a model for making use of graphical capability.  Make what is 
> now the body into a tabbed frame.  You can probably adopt the log pane code 
> with little change.  The standard body display becomes one of the tabs, one 
> that is always there.  Nodes would pick up an additional piece:  Currently 
> nodes have headline data (p.h) and text data (p.b).  They can be enhanced 
> to contain, say, p.canvas, which would be data or drawing instructions for 
> a canvas.  There might end up being a use for several types of p.canvas, 
> say p.canvas_x.  So we'd eventually need some machinery to accommodate that.
>
> I'll pick this up in my next post, since this one is already getting too 
> long.
> On Monday, March 21, 2022 at 10:45:01 AM UTC-4 gates...@gmail.com wrote:
>
>> While I anticipate pushback on this idea, I am wholeheartedly for it.  I 
>> have long wanted such a feature, but couldn't figure out just how to word 
>> it.
>>
>> On Mon, Mar 21, 2022 at 10:42 AM tbp1...@gmail.com  
>> wrote:
>>
>>> Leo's nodes are basically text-only nodes.  The text is 

Re: Could Leo Have Canvas-type Nodes?

[tbp1...@gmail.com]

I'm getting very enthusiastic about this notion because I can see how it 
could work - from  user interface, architectural, and implementation points 
of view.  Of course, the devil is in the details and I'm only looking at an 
overall picture.  It seems to me that a small change in Leo's design would 
open up all kinds of possibilities.  My thinking is guided by a number of 
features that already exist, especially 1) the tabbed Log pane; 2) the 
machinery behind the display of @pyplot nodes, and 3) the viewrendered and 
viewrendered3 plugins.

Let's start with the Log pane.  Whoever came up with it had a brilliant 
idea. Most users are probably familiar with the Find and Nav tabs, and 
possibly the Completion and Spell tabs.  You click on a tab and get a 
completely different view.  What you may not realize is that a tab is just 
the display device for an entire mini-application, in the form of scripts 
and a set of one or more "widgets".  To hook it into the log pane with its 
own tab is remarkably simple, programming-wise - this is the brilliant 
part.  You just give the top-level widget and a tab name to the log pane 
and the pane sets up all the tab and switching machinery for you.  So a tab 
could contain almost anything - a web browser, a dictionary, you name it.  
If it has a single top-level display widget and code behind that, it can 
get its own tab in the log pane.  The scripts for the tab have access to 
all of Leo's code and data, so they can do just about whatever they like.  
Tabs can be installed by plugins, bit also by non-plugin scripts.

So this is a model for making use of graphical capability.  Make what is 
now the body into a tabbed frame.  You can probably adopt the log pane code 
with little change.  The standard body display becomes one of the tabs, one 
that is always there.  Nodes would pick up an additional piece:  Currently 
nodes have headline data (p.h) and text data (p.b).  They can be enhanced 
to contain, say, p.canvas, which would be data or drawing instructions for 
a canvas.  There might end up being a use for several types of p.canvas, 
say p.canvas_x.  So we'd eventually need some machinery to accommodate that.

I'll pick this up in my next post, since this one is already getting too 
long.
On Monday, March 21, 2022 at 10:45:01 AM UTC-4 gates...@gmail.com wrote:

> While I anticipate pushback on this idea, I am wholeheartedly for it.  I 
> have long wanted such a feature, but couldn't figure out just how to word 
> it.
>
> On Mon, Mar 21, 2022 at 10:42 AM tbp1...@gmail.com  
> wrote:
>
>> Leo's nodes are basically text-only nodes.  The text is available from 
>> the node's body, typically p.b, or the headline, p.h.  I wonder if there 
>> could be another part of a node, a drawing canvas.  Perhaps p.cnvs?  If we 
>> could figure out how to converse with the canvas of a node, then we could 
>> visualize anything we like. 
>>
>> Alternatively, perhaps there could be a new node type, one that has only 
>> a canvas, with no text body - that would be more like the Jupyter approach.
>>
>> Having a canvas as a built-in part of a node could fill a conspicuous 
>> lack, the inability to display graphical information.  There are 
>> workarounds.  The @pyplot node type is one, and writing graphics as SVG to 
>> a node and showing that node with VR3 is another.  Writing RsT or Markdown 
>> referencing an image to a node and displaying it in VR3 is a third. This 
>> gives you mixed text and graphics.  But these methods are all limited and 
>> clumsy.
>>
>> A graphics node should include the ability to have links that point back 
>> into Leo outlines, or at least its own outline.  This capability would make 
>> Leo stand out in comparison to say Jupyter, which otherwise has so many 
>> good features.
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/leo-editor/bf345490-57fc-4dc6-981a-2c2b9f796826n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/48aa298f-a1de-4b97-9ccc-a9b974d4b044n%40googlegroups.com.

Re: Could Leo Have Canvas-type Nodes?

[Jacob Peck]

While I anticipate pushback on this idea, I am wholeheartedly for it.  I
have long wanted such a feature, but couldn't figure out just how to word
it.

On Mon, Mar 21, 2022 at 10:42 AM tbp1...@gmail.com 
wrote:

> Leo's nodes are basically text-only nodes.  The text is available from the
> node's body, typically p.b, or the headline, p.h.  I wonder if there could
> be another part of a node, a drawing canvas.  Perhaps p.cnvs?  If we could
> figure out how to converse with the canvas of a node, then we could
> visualize anything we like.
>
> Alternatively, perhaps there could be a new node type, one that has only a
> canvas, with no text body - that would be more like the Jupyter approach.
>
> Having a canvas as a built-in part of a node could fill a conspicuous
> lack, the inability to display graphical information.  There are
> workarounds.  The @pyplot node type is one, and writing graphics as SVG to
> a node and showing that node with VR3 is another.  Writing RsT or Markdown
> referencing an image to a node and displaying it in VR3 is a third. This
> gives you mixed text and graphics.  But these methods are all limited and
> clumsy.
>
> A graphics node should include the ability to have links that point back
> into Leo outlines, or at least its own outline.  This capability would make
> Leo stand out in comparison to say Jupyter, which otherwise has so many
> good features.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/leo-editor/bf345490-57fc-4dc6-981a-2c2b9f796826n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAJ1i%2BSYRpxpZtpAzmkMM8bNdc1As0qP2AcVvhfO8LuuSjgk37Q%40mail.gmail.com.