Could Leo Have Canvas-type Nodes?

[tbp1...@gmail.com]

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.

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

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

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

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

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

[tbp1...@gmail.com]

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

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

[Edward K. Ream]

On Mon, Mar 21, 2022 at 9:45 AM Jacob Peck <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.

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

[Edward K. Ream]

On Tue, Mar 22, 2022 at 9:17 AM tbp1...@gmail.com <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

[Edward K. Ream]

On Tue, Mar 22, 2022 at 9:24 AM tbp1...@gmail.com <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

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