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 <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 >>> >>> <https://groups.google.com/d/msgid/leo-editor/bf345490-57fc-4dc6-981a-2c2b9f796826n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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/4c37ac35-bfc8-4330-bfbb-5878b6f42c3cn%40googlegroups.com.
