How do I organize my panes, now that the 'easter egg' interface is gone?

[Jacob Peck]

Alt-0 to open my VR pane now opens in a really tiny box underneath my log, and it's kinda unusable there.  I'm not seeing in the docs or leoSettings file how to move things around any longer.  This feels like a downgrade, unless I'm just missing some commands or something (and even if there are commands, the right-click context menus were supremely useful for this. so I didn't have to memorize new things).

Sorry if this sounds frustrated or critical, that's not my intention. I'm honestly just trying to figure this brave new world out.  The 'old way' may have had its implementation woes, but the user facing experience was at least easier to grok to me.  Please point me in the right direction, so I can educate myself.

Thanks,

Jake

[Thomas Passin]

If you want to use viewrendered3 instead of viewrendered, I have scripts that will open it in the same pane as the body editor, and you can toggle between VR3 and the body editor.  I have another one that can open VR3 in the log pane instead of on a small panel under it.  I'm pretty sure a small change would make them work for VR but I  haven't tried it.

Otherwise, I have a script that moves the log frame from its default position under the tree to a new panel to the right of the body editor.  This does the same thing as one of the old splitter menu items. I've put these scripts into buttons so they are easy to use.

Actually it's easier to write dedicated little scripts now than it used to be with the old nested splitters.  Mainly you have to know the names of the frames and splitters you are interested in.  Edward posted a command that will list all the widgets and their names in a hierarchical view.  I forget whether it's a built-in Leo command or not.

My guess is that eventually a default Leo installation will have several of these little commands, once we get enough experience to know what they should be.  Here's my script to swap the log frame to a position beside the body editor.  It finds the splitter of interest, then finds the widget for the log frame, and inserts it into the same splitter as the body editor - that automatically puts it beside or below the body editor depending on the orientation you are using:

"""Move Nav frame between main and secondary splitters."""

gui = g.app.gui

ms = gui.find_widget_by_name(c, 'main_splitter')
ss = gui.find_widget_by_name(c, 'secondary_splitter')
lf = gui.find_widget_by_name(c, 'logFrame')

nav_in_secondary = ss.findChild(type(lf), "logFrame")
target = ms if nav_in_secondary else ss
target.addWidget(lf)

# Equalize sizes - "100000" must be larger than any of the widgets...
# and well less than MAX_INT
target.setSizes([100_000] * len(target.sizes()))

If you are using vertical orientation instead or horizonal (or maybe the other way around, I forget the terminology) this may not be what you want but you can change the orientation with the Window menu item Toggle-Split-Direction .

Until we have more of these commands, post what functionality you would like to have  and perhaps Edward or I will be able to write one.

[Edward K. Ream]

On Wed, Jul 17, 2024 at 4:14 PM Thomas Passin <tbp1...@gmail.com> wrote:

Actually it's easier to write dedicated little scripts now than it used to be with the old nested splitters.  Mainly you have to know the names of the frames and splitters you are interested in.  Edward posted a command that will list all the widgets and their names in a hierarchical view.  I forget whether it's a built-in Leo command or not.

'show-qt-widgets' is an official command.

You only need to remember <alt-x>show<tab>. Tab completion will do the rest.

Edward

[Thomas Passin]

Here's a similar script that will toggle viewrendered  in a new pane next to the body:

import leo.plugins.viewrendered as v
h = c.hash()
vr = v.controllers.get(h)

if not vr:
    v.controllers[h] = vr = v.ViewRenderedController(c)

if vr.isVisible():
    c.doCommandByName('vr-hide')
else:
    ms = g.app.gui.find_widget_by_name(c, 'main_splitter')
    ms.addWidget(vr)
    ms.setSizes([100_000] * len(ms.sizes()))
    c.doCommandByName('vr-show')

[Jacob Peck]

Thank you, Thomas and Edward, for your inputs and examples.

As a Leo user (and occasional dev/contributor) over the last 12 years and change, removing the ‘Easter egg’ menus feels like the largest regression I’ve seen Leo go through.   Needing to write custom commands and scripts to do now what used to take about three clicks before is just unfortunate.

I don’t know how to satisfy both the needs of devs and the needs of users in this instance.  It just feels a bit sad that the UI lost in this particular fight.  And I don’t think that a bevy of new commands is the right way to go about it moving forward, either — many users never ever interact with the minibuffer.  I certainly don’t use it if I can help it.  And Leo is my Everything Program for over a decade now.

I will script up the things I need to get the work done that I need to do, but in all honesty this is a huge loss for those who aren’t programmers and used to be among the users Leo welcomed more thoroughly.  It feels a little bit like every passing version removes more and more user-facing features, and alienates non-programming folks even further.

Sorry to complain, just airing my $0.02 (worth even less now with inflation).

Jake

On Jul 17, 2024, at 7:47 PM, Thomas Passin <tbp1...@gmail.com> wrote:

Here's a similar script that will toggle viewrendered  in a new pane next to the body:

--
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/aed731a4-6add-493c-a087-0e725608c377n%40googlegroups.com.

[Thomas Passin]

On Wednesday, July 17, 2024 at 8:44:35 PM UTC-4 gates...@gmail.com wrote:

Thank you, Thomas and Edward, for your inputs and examples.

As a Leo user (and occasional dev/contributor) over the last 12 years and change, removing the ‘Easter egg’ menus feels like the largest regression I’ve seen Leo go through.   Needing to write custom commands and scripts to do now what used to take about three clicks before is just unfortunate.

I don’t know how to satisfy both the needs of devs and the needs of users in this instance.  It just feels a bit sad that the UI lost in this particular fight.  And I don’t think that a bevy of new commands is the right way to go about it moving forward, either — many users never ever interact with the minibuffer.  I certainly don’t use it if I can help it.  And Leo is my Everything Program for over a decade now.

I will script up the things I need to get the work done that I need to do, but in all honesty this is a huge loss for those who aren’t programmers and used to be among the users Leo welcomed more thoroughly.  It feels a little bit like every passing version removes more and more user-facing features, and alienates non-programming folks even further.

Sorry to complain, just airing my $0.02 (worth even less now with inflation).

I was unhappy too or at least concerned when Edward brought up changing the splitter interface.  But unlike you, I always had trouble using it, or even knowing what the various context menu items would do.  And when I got a configuration I liked, it was hard for me to reproduce.  I was constantly irritated and tried to avoid using the splitter menu.  It also made programming various things in plugins tricky at best. The new interface is much better, I think, at least for programmers.

I certainly agree with you about having built-in commands that are easy to use to replace some of the splitter menu commands.  Ordinary users shouldn't have to write scripts to do basic configuration.  OTOH, just what are those configuration things that people want to do? It's a little hard to know until they speak up.  I don't know about Edward, but I hope we can learn what people want the most and start to build them in.

And, as always, it's hard to figure out how to let people find out how to do things they want.  Suggestions greatly welcomed!

[Jacob Peck]

After sending, I realized I omitted a statement I meant to include:

```

This being the largest regression I've seen Leo go through in 12 years is a testament to how fantastic this app is.  Which also, somehow, heightens it absence.  It's just a little less 'perfect' now, even as it's more structurally sound 'under the hood'.
```

As a script writer, I'm sure I'll much appreciate the new splitter setup -- some of my 'LeoApps' had done atrocious things to get a consistent layout 😅.  I just haven't gotten into the new splitter API and I really don't think usual users should ever have to go that far.

I think a possible starting point for a series of commands could be (assuming a potential layout of thirds, either vertical or horizontal):

move-XXX-to-top (alias move-XXX-to-left)

move-XXX-to-bottom (alias move-XXX-to-right)

move-XXX-to-center

where XXX is a 'named' pane (log, body, vr, vr3, etc)

And where the commands interpret the appropriate movement instructions from whether the layout is currently horizontal or vertical via the Split Direction (thus the aliases -- same command under the hood, just with user-friendly names for cognitive ease).

Perhaps there could even be an API to 'register' new named panes (which would auto-generate and auto-populate the appropriate commands).  And a matching `list-all-named-panes` command (and function somewhere under c) that would get you the list of registered named panes.  With such a thing, plugins that add new panes could just say to Leo's core "hey, I'm providing a widget called foobar, you do the layout work".

Just spitballing.  Thanks for coming to my TED talk :)

Jake

--

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/add5bed1-e9dc-49fb-a2f5-e522450cbe2bn%40googlegroups.com.

[Edward K. Ream]

On Wed, Jul 17, 2024 at 8:51 PM Jacob Peck <gates...@gmail.com> wrote:

This being the largest regression I've seen Leo go through in 12 years is a testament to how fantastic this app is.  Which also, somehow, heightens it absence.  It's just a little less 'perfect' now, even as it's more structurally sound 'under the hood'.

Thanks for your comments. Over the years I've deleted several overly-complex features. I've never regretted any of those choices and I don't regret removing the free_layout plugin.

Being less complex under the hood is worth any temporary pain.

As a script writer, I'm sure I'll much appreciate the new splitter setup -- some of my 'LeoApps' had done atrocious things to get a consistent layout 😅. 

Exactly. And you weren't the only user that had trouble.

I just haven't gotten into the new splitter API and I really don't think usual users should ever have to go that far.

Leo now has a new widget API, consisting of just a few new methods.

I think a possible starting point for a series of commands could be ...

I agree that some help would be welcome.  Thomas's scripts are an excellent starting point.

Those scripts are a good ending point if you are good with changing the layout using `@button` nodes.

I don't recommend enabling scripts on startup. It's too big a security concern. Instead, I recommend creating new layout plugins.  Outlines could enable the most appropriate plugin.

Summary

- There is no need for yet another API or yet more commands.

- `@button` scripts are best when one wants to allow multiple layouts in an outline.

-  Bespoke layout plugins are another way to package non-standard layouts.

HTH.

Edward

[Thomas Passin]

On Thursday, July 18, 2024 at 7:05:08 AM UTC-4 Edward K. Ream wrote:

On Wed, Jul 17, 2024 at 8:51 PM Jacob Peck <gates...@gmail.com> wrote:

This being the largest regression I've seen Leo go through in 12 years is a testament to how fantastic this app is.  Which also, somehow, heightens it absence.  It's just a little less 'perfect' now, even as it's more structurally sound 'under the hood'.

I agree that some help would be welcome.  Thomas's scripts are an excellent starting point.

Those scripts are a good ending point if you are good with changing the layout using `@button` nodes.

Too many buttons aren't good. Once one has a script, it can also be added to a menu, as another possibility.  That's what I have done with a script to move the log frame from the tree's splitter to the body's splitter.  Partly which way to go it depends on when and how often you use the script.

 

I don't recommend enabling scripts on startup. It's too big a security concern. Instead, I recommend creating new layout plugins.  Outlines could enable the most appropriate plugin.

Summary

- There is no need for yet another API or yet more commands.

- `@button` scripts are best when one wants to allow multiple layouts in an outline.

-  Bespoke layout plugins are another way to package non-standard layouts.

I think that Jacob's concern is that out of the box there is no way for a user to set up or choose a different layout, except for the Window/Toggle-Split-Direction  menu item.  That's somewhat useful but some users will want more layout possibilities. With the nested splitter context menu, at least there were possibilities that were obscure in the extreme but could be experimented with. I think that most users don't want to or aren't willing to spend the time to learn to write scripts to create new layouts.

I think that layout plugins are a promising way forward, and we should provide several so Leo will have them out-of-the-box ... as soon as we can learn what layouts people want ...

[Jacob Peck]

To be brief and frank -- @buttons are an objectively bad solution to this for a casual user.  An @button to set their favorite layout is:

1) inflexible -- a button will set a specific layout, and nothing else

2) bespoke -- require development time of the user, or to go begging on the mailing list for someone else to do the work, which is objectively a bad UX

3) clutter -- would add both cognitive and visual clutter to an outline

I feel that 'layout plugins' would assist with this, but they'd still be supremely inflexible.  For the non-programming user, we went from 'you can have any layout you want' to 'here are your choices, get over it'.

To point #1, with the old easter-egg approach, I frequently manipulated layouts dynamically within the same workbook, to achieve what I needed at the time, on the fly. Some layouts I only ended up using for a few minutes, as suited my workflow. There was also the layout saving+loading mechanism that helped switch when desired to a series of 'stable' layouts, across all outlines.

To #2, requiring a user to a) know the API, and b) be willing to put in the effort to write a custom bespoke script just to move a panel around.  This is a bit much.

#3 is nothing new in Leo world, but is just one more point of friction for new users.

If the splitters had context menus to add new splits, and panes had click&drag handles to let you move them around, my whole issue would be resolved.  No new commands, no new plugins, no absurd development time requests of basic users.  The music app Foobar2000 does this by having a togglable 'layout editing mode' that only surfaces these features when editing the layout -- otherwise your layout is set in stone.  Just one model to look to for inspiration -- it works well there, extremely so.

Again, my $0.02.  I don't ask you to regret removing free_layout, just to consider what it is you actually put up in its place.  I also ask you to not neglect mouse users -- we are the majority of computer users.

Jake

--

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/502b437d-c2bb-445a-b2d1-5a6dda37abafn%40googlegroups.com.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 7:24 AM Jacob Peck <gates...@gmail.com> wrote:

@buttons are an objectively bad solution to this for a casual user.

That's why a set of layout plugins would be a valuable addition to Leo.

I feel that 'layout plugins' would assist with this, but they'd still be supremely inflexible.  For the non-programming user, we went from 'you can have any layout you want' to 'here are your choices, get over it'.

You are overstating your case. Let's focus on creating a set of useful layout plugins.

Edward

[Thomas Passin]

On Thursday, July 18, 2024 at 8:24:52 AM UTC-4 gates...@gmail.com wrote:

To be brief and frank -- @buttons are an objectively bad solution to this for a casual user.  An @button to set their favorite layout is:

1) inflexible -- a button will set a specific layout, and nothing else

2) bespoke -- require development time of the user, or to go begging on the mailing list for someone else to do the work, which is objectively a bad UX

3) clutter -- would add both cognitive and visual clutter to an outline

@buttons are certainly not a general solution. They can be useful but are limited.  The same is true for new menu items.

 

I feel that 'layout plugins' would assist with this, but they'd still be supremely inflexible.  For the non-programming user, we went from 'you can have any layout you want' to 'here are your choices, get over it'.

To point #1, with the old easter-egg approach, I frequently manipulated layouts dynamically within the same workbook, to achieve what I needed at the time, on the fly. Some layouts I only ended up using for a few minutes, as suited my workflow. There was also the layout saving+loading mechanism that helped switch when desired to a series of 'stable' layouts, across all outlines.

I found it very hard to understand what results I was going to get with that old interface.  Yes, I would save and restore named  layouts once I got something I liked, and sometimes they got lost. I only ever had a few named layouts because managing and even remembering what they were for they were wasn't easy.  So for me they were a mixed blessing.

 

To #2, requiring a user to a) know the API, and b) be willing to put in the effort to write a custom bespoke script just to move a panel around.  This is a bit much.

I agree with this.  It's not the same as the question of whether to only offer pre-canned layouts or to find ways to let a user roll their own.

 

#3 is nothing new in Leo world, but is just one more point of friction for new users.

If the splitters had context menus to add new splits, and panes had click&drag handles to let you move them around, my whole issue would be resolved.  No new commands, no new plugins, no absurd development time requests of basic users.

I don't know why, but drag-n-drop often seems to be a problem with Leo.  Dragging a node in the tree to a new spot works but it's touchy and sometimes doesn't get the node where you want.  Sometimes multiple nodes get highlighted and I don't know why, but only one of them will get moved by the mouse. It's possible to highlight more than one node but a delete will only deleted one of them, and it's not always the one I expect.  Dropping files (other than outlines) doesn't work reliably yet.  And so on.  I think that dragging operations in general (in Qt but in other frameworks too) can be hard to get working right. I personally don't have much experience in this area so don't have anything useful to offer.

 

[Thomas Passin]

Plugins for layouts would be helpful but don't completely solve the question of a simple intuitive user interface.  A layout plugin can provide a new menu item, @button, or minibuffer command that will create the new layout.  A better user interface would, as Jacob writes, let a user see and click on the layout wanted, or even better to manipulate panes on a simplified view to create a new layout. I would say that the latter would be awfully hard to to create relative to its benefits, but the former would be much easier.

Leo's menu construction system uses a declarative approach.  The desired menu arrangement is specified in a @settings file in a declarative way.  It's fairly easy and very useful.  I expect that a similar declarative approach to layouts would be fruitful.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 8:00 AM Thomas Passin <tbp1...@gmail.com> wrote:

>> Let's focus on creating a set of useful layout plugins.

> Plugins for layouts would be helpful but don't completely solve the question of a simple intuitive user interface.

It's all too easy to design a platinum solution when a silver (or even tin) solution will get us 90% there.

True, `@button` nodes aren't a general solution, but they make easy prototypes.

First things first: how many new layouts do people want and what are they?

Let's stop bitching and do something constructive.

Edward

[Jacob Peck]

Characterizing criticism and concerns as 'bitching' is quite off putting.  But brushing that aside...

A starter pack could include these layouts: https://gist.github.com/gatesphere/82c9f67ca7b65d09e85208e0b2f7eca1

Notably, quadrants and vertical thirds is how vr *used to act* for the two split directions, but no longer seems to.

Jake

--

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/CAMF8tS0ZpYfLrs94EbmyOWf5Em-ONoOL-VMQ5rmAk4t0qctXrw%40mail.gmail.com.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 10:26 AM Jacob Peck <gates...@gmail.com> wrote:

Characterizing criticism and concerns as 'bitching' is quite off putting.

I apologize for my brusque remarks.

Still, it seems unfair to complain about what used to be without acknowledging that the free_layout plugin prevented static definitions of layouts.

Here is a straightforward plan that requires no new Leonine features:

- Create @button nodes for the four layouts in the "starter pack."

  Their docstrings will describe the layouts.

- Once we have acceptable @button scripts, we can easily convert them to plugins.

- A new info item can summarize these new plugins.

  This item can include screenshots.

I'll be happy to help with the four layouts if you like.

Edward

[Thomas Passin]

I've already got a script to do Layout # 1 in Jacob's linked layouts.  If you have #1, you can toggle between it and #4 using the existing Window/Toggle-Split-Direction menu item.  I've attached screen shots of the two layouts, and the script is below:

import leo.plugins.viewrendered3 as v3
h = c.hash()
vr3 = v3.controllers.get(h)

if not vr3:
    v3.controllers[h] = vr3 = v3.ViewRenderedController3(c)

if vr3.isVisible():
    c.doCommandByName('vr3-hide')

else:
    ms = g.app.gui.find_widget_by_name(c, 'main_splitter')

    ms.addWidget(vr3)
    ms.setSizes([100_000] * len(ms.sizes()))
    vr3.show()

I've had this script in a custom menu for some time, though I find I don't use it much (I use a different layout most of the time).  The UI aspect of this is how to package such commands to make it easy for a user to find them and use them.

[Thomas Passin]

I forgot to point out that in my script (above), you can get the same result for VR instead of VR3 by simply dropping the "3" from all the lines of code.

Attached is my custom menu from which I can run several of these scripts.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 12:08 PM Thomas Passin <tbp1...@gmail.com> wrote:

I've already got a script to do Layout # 1 in Jacob's linked layouts.  If you have #1, you can toggle between it and #4 using the existing Window/Toggle-Split-Direction menu item.  I've attached screen shots of the two layouts, and the script is below:

Excellent. Imo, #4 should (eventually) be a separate script so that users can get it directly (without having to do toggle-split-direction.

On to 2 and 3!

Edward

[Edward K. Ream]

On Thu, Jul 18, 2024 at 12:15 PM Thomas Passin <tbp1...@gmail.com> wrote:

> I forgot to point out that in my script (above), you can get the same result for VR instead of VR3 by simply dropping the "3" from all the lines of code.

Good to know.

> Attached is my custom menu from which I can run several of these scripts.

Interesting.

> The UI aspect of this is how to package such commands to make it easy for a user to find them and use them.

Imo, the UI aspect is minor. Users (with just a little prompting) should be able to find the plugins.

Otoh, a new menu (similar to your custom menu) might be appropriate.

Edward

[Thomas Passin]

Yes indeed.  You just need to add orientation detection to the script.  I used to know how to do that but I don't remember  just now.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 12:27 PM Thomas Passin <tbp1...@gmail.com> wrote:

Excellent. Imo, #4 should (eventually) be a separate script so that users can get it directly (without having to do toggle-split-direction.

Yes indeed.  You just need to add orientation detection to the script.  I used to know how to do that but I don't remember  just now.

Now we're getting somewhere :-)

Converting a prototype (@button script) to a plugin opens up new capabilities.  Examples:

1. There is a setting that specifies initial orientation. A plugin could use that setting, but a plugin could try other strategies, such as examining the widget hierarchy directly.

2. Plugins can queue code to run after Leo's has created outline frames. Such code can discover whether VR or VR3 is running (if either). So the plugin can add the "3" if necessary.  Understand?

Summary

Keep the @button prototypes dead simple. Add nifty features to the corresponding plugins if you like.

Edward

[Thomas Passin]

On Thursday, July 18, 2024 at 1:37:08 PM UTC-4 Edward K. Ream wrote:

1. There is a setting that specifies initial orientation. A plugin could use that setting, but a plugin could try other strategies, such as examining the widget hierarchy directly.

The user might have changed the orientation so you don't want to use the initial orientation setting.  IIRC, a splitter can be interrogated for its orientation.  So you just get the main splitter and ask it.

 

2. Plugins can queue code to run after Leo's has created outline frames. [snip]

We need an example plugin that shows how to do this. I suppose that it's registering for the appropriate Leo event, right?

 

Summary

Keep the @button prototypes dead simple. Add nifty features to the corresponding plugins if you like.

@buttons are good for prototyping, all right.  I even used them (in my Workbook, no less) while developing the current line highlighting code and the right margin line code.  The buttons monkey-patched my prototype code into Leo's core while Leo was running.  This approach let me avoid changing any Leo core code until the techniques were worked out. 

[Edward K. Ream]

On Thu, Jul 18, 2024 at 12:55 PM Thomas Passin <tbp1...@gmail.com> wrote:

> The user might have changed the orientation so you don't want to use the initial orientation setting.  IIRC, a splitter can be interrogated for its orientation.  So you just get the main splitter and ask it.

Good point for @button scripts.

>>2. Plugins can queue code to run after Leo's has created outline frames. [snip]

>We need an example plugin that shows how to do this. I suppose that it's registering for the appropriate Leo event, right?

Yes. after-create-leo-frame.

Edward

[Thomas Passin]

And here's a script to create Jacob's Layout #3 "render-focused".  This script will work for either VR or VR3 if you just change the module imported at the top.

"""Change layout to Gates # 3 "render-focused"."""
# ref: https://gist.github.com/gatesphere/82c9f67ca7b65d09e85208e0b2f7eca1#file-render-focused

from leo.core.leoQt import Orientation
import leo.plugins.viewrendered3 as v3
cmd = 'vr3-show' if 'ed3' in v3.__name__ else 'vr-toggle'

gui = g.app.gui

ms = gui.find_widget_by_name(c, 'main_splitter')
ss = gui.find_widget_by_name(c, 'secondary_splitter')
lf = gui.find_widget_by_name(c, 'logFrame')

of = gui.find_widget_by_name(c, 'outlineFrame')
edf = gui.find_widget_by_name(c, 'bodyFrame')

init_orientation = ms.orientation()
g.es(init_orientation)
if init_orientation != Orientation.Horizontal:
    ms.setOrientation(Orientation.Horizontal)
    ss.setOrientation(Orientation.Vertical)

ms.addWidget(lf)  # Temporarily to get body to be second
ss.addWidget(edf)
ss.addWidget(lf)

h = c.hash()
vr3 = v3.controllers.get(h)

if not vr3:
    v3.controllers[h] = vr3 = v3.ViewRenderedController3(c)

if not vr3.isVisible():

    ms = g.app.gui.find_widget_by_name(c, 'main_splitter')
    ms.addWidget(vr3)
    ms.setSizes([100_000] * len(ms.sizes()))

    c.doCommandByName(cmd)

ss.setSizes([100_000] * len(ss.sizes()))
ms.setSizes([100_000] * len(ms.sizes()))

[Jacob Peck]

Thank you both for your work on this.  I wasn't trying to get free labor, but I do appreciate it.  I'll get to work on number 2 as time allows (unfortunately fleeting at the moment).

An addition of commands that I think would be beneficial, would be:

swap-X-with-Y

Where X and Y are names of panes -- it would simply swap those panes' locations, within one of these standard layouts.  That combination (these four basic frameworks and pane-swapping commands) would give me about 95% of what I used previously, and I think would be a reasonable addition.  But again, this might require a 'registration' API to register new panes by name to generate these commands.

Thanks,

Jake

--
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/525e9a45-2e34-4040-a9ec-f0e656f3da2fn%40googlegroups.com.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 4:27 PM Thomas Passin <tbp1...@gmail.com> wrote:

And here's a script to create Jacob's Layout #3 "render-focused".  This script will work for either VR or VR3 if you just change the module imported at the top.

Thanks for this. The script works for me with VR3 but not VR. I'll post a revised script asap.

Edward

[Edward K. Ream]

On Thu, Jul 18, 2024 at 7:44 PM Jacob Peck <gates...@gmail.com> wrote:

Thank you both for your work on this.  I wasn't trying to get free labor, but I do appreciate it. 

You're welcome. Your proposed layouts are a big step forward. Thomas and I can probably take things from here.

Ultimately, it's my responsibility to give Leonistas the layouts they want.

Edward

[Thomas Passin]

It worked for both for me. If the pane on the right shows up but VR isn't showing anything, try running the "vr-show'" command.  I went to the toggle command when vr-show didn't work, but maybe you had VR visible already and the toggle turned it off.

The intended import change is from 

import leo.plugins.viewrendered3 as v3

to

import leo.plugins.viewrendered as v3

The naming as "v3" and "vr3" when the desired widget is VR is a bit of cognitive dissonance.  It was simpler that way for a quick proof of principle.

[Jacob Peck]

Here's my go at a `quadrants` layout:

```
from leo.core.leoQt import Orientation, QtWidgets
import leo.plugins.viewrendered as vr

gui = g.app.gui

def make_splitter():
  w = QtWidgets.QSplitter()
  w.setObjectName('body_splitter')
  return w

ms = gui.find_widget_by_name(c, 'main_splitter')
ss = gui.find_widget_by_name(c, 'secondary_splitter')

edf = gui.find_widget_by_name(c, 'bodyFrame')

# add vertical splitter to ms (hosting only the editor)
body_splitter = make_splitter()
body_splitter.setOrientation(Orientation.Vertical)
ms.addWidget(body_splitter)
body_splitter.addWidget(edf)

# add vr pane
h = c.hash()
vrp = vr.controllers.get(h)

if not vrp:
    vr.controllers[h] = vrp = vr.ViewRenderedController(c)

if not vrp.isVisible():
    body_splitter.addWidget(vrp)
    body_splitter.setSizes([100_000] * len(body_splitter.sizes()))
    ms.setSizes([100_000] * len(ms.sizes()))
    ss.setSizes([100_000] * len(ss.sizes()))
    c.doCommandByName('vr-show')
```

I wasn't sure exactly which invocations of setSizes I needed, so I just did all of them to perfectly balance everything.  Thanks for the boilerplate of the script, Thomas -- supremely useful in combination with Edward's info item #3982.

Jake

--

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/a40175bf-e694-4491-bf07-34dcebf549a0n%40googlegroups.com.

[Thomas Passin]

Great!  Will test it soon.

Meanwhile, here's an improvement on my script for "render-focused".  The cognitive dissonance is gone, unnecessary or redundant code is gone, and it works with VR even if VR is already open in some other layout.

"""Change layout to Gates # 3 "render-focused"."""
# ref: https://gist.github.com/gatesphere/82c9f67ca7b65d09e85208e0b2f7eca1#file-render-focused

from leo.core.leoQt import Orientation

import leo.plugins.viewrendered3 as vx
cmd = 'vr3-show' if 'ed3' in vx.__name__ else 'vr-toggle'

gui = g.app.gui

ms = gui.find_widget_by_name(c, 'main_splitter')
ss = gui.find_widget_by_name(c, 'secondary_splitter')

lf = gui.find_widget_by_name(c, 'logFrame')

edf = gui.find_widget_by_name(c, 'bodyFrame')

init_orientation = ms.orientation()

if init_orientation != Orientation.Horizontal:
    ms.setOrientation(Orientation.Horizontal)
ss.setOrientation(Orientation.Vertical)

ms.addWidget(lf)  # Temporarily to get body to be second
ss.addWidget(edf)
ss.addWidget(lf)

h = c.hash()

vrx = vx.controllers.get(h)

if not vrx:
    vx.controllers[h] = vrx = vx.ViewRenderedController3(c)

ms.addWidget(vrx)
if vrx.isHidden():

    c.doCommandByName(cmd)

ss.setSizes([100_000] * len(ss.sizes()))
ms.setSizes([100_000] * len(ms.sizes()))

[Edward K. Ream]

On Thu, Jul 18, 2024 at 9:06 PM Thomas Passin <tbp1...@gmail.com> wrote:

Meanwhile, here's an improvement on my script for "render-focused".  The cognitive dissonance is gone, unnecessary or redundant code is gone, and it works with VR even if VR is already open in some other layout.

It works for me!  Thanks.

Next, I'd like to replace the vx switch. Leo's plugins manager can tell us whether VR or VR3 is running.

Edward

[Edward K. Ream]

On Fri, Jul 19, 2024 at 5:27 AM Edward K. Ream <edre...@gmail.com> wrote:

> Next, I'd like to replace the vx switch. Leo's plugins manager can tell us whether VR or VR3 is running.

Here is the dynamic version:

Top level:

"""Change layout to Jacob Peck's layout # 3."""
# ref: https://gist.github.com/gatesphere/82c9f67ca7b65d09e85208e0b2f7eca1#file-render-focused
g.cls()
from leo.core.leoQt import Orientation

@others  # Define switch_layout.

pc = g.app.pluginsController
if pc.isLoaded('leo.plugins.viewrendered3'):
    cmd = 'vr3-show'
    import leo.plugins.viewrendered3 as vx
    switch_layout(cmd, vx)
elif pc.isLoaded('leo.plugins.viewrendered'):
    cmd = 'vr-toggle'
    import leo.plugins.viewrendered as vx
    switch_layout(cmd, vx)
else:
    print('No VR plugin enabled')

The only child node is the following. It's Thomas's code wrapped in a function:

def switch_layout(cmd: str, vx: Any) -> None:

    gui = g.app.gui
    ms = gui.find_widget_by_name(c, 'main_splitter')
    ss = gui.find_widget_by_name(c, 'secondary_splitter')
    lf = gui.find_widget_by_name(c, 'logFrame')
    edf = gui.find_widget_by_name(c, 'bodyFrame')

    init_orientation = ms.orientation()
    if init_orientation != Orientation.Horizontal:
        ms.setOrientation(Orientation.Horizontal)
    ss.setOrientation(Orientation.Vertical)

    ms.addWidget(lf)  # Temporarily to get body to be second
    ss.addWidget(edf)
    ss.addWidget(lf)

    h = c.hash()
    vrx = vx.controllers.get(h)

    if not vrx:
        vx.controllers[h] = vrx = vx.ViewRenderedController3(c)

    ms.addWidget(vrx)
    if vrx.isHidden():
        c.doCommandByName(cmd)

    ss.setSizes([100_000] * len(ss.sizes()))
    ms.setSizes([100_000] * len(ms.sizes()))

Edward

And here is the copy of the entire tree:

<?xml version="1.0" encoding="utf-8"?>
<!-- Created by Leo: https://leo-editor.github.io/leo-editor/leo_toc.html -->
<leo_file xmlns:leo="https://leo-editor.github.io/leo-editor/namespaces/leo-python-editor/1.1" >
<leo_header file_format="2"/>
<vnodes>
<v t="ekr.20240719052742.1"><vh>dynamic layout3</vh>
<v t="ekr.20240719054147.1"><vh>switch_layout</vh></v>
</v>
</vnodes>
<tnodes>
<t tx="ekr.20240719052742.1">"""Change layout to Jacob Peck's layout # 3."""
# ref: https://gist.github.com/gatesphere/82c9f67ca7b65d09e85208e0b2f7eca1#file-render-focused
g.cls()
from leo.core.leoQt import Orientation

@others  # Define switch_layout.

pc = g.app.pluginsController
if pc.isLoaded('leo.plugins.viewrendered3'):
    cmd = 'vr3-show'
    import leo.plugins.viewrendered3 as vx
    switch_layout(cmd, vx)
elif pc.isLoaded('leo.plugins.viewrendered'):
    cmd = 'vr-toggle'
    import leo.plugins.viewrendered as vx
    switch_layout(cmd, vx)
else:
    print('No VR plugin enabled')
</t>
<t tx="ekr.20240719054147.1">def switch_layout(cmd: str, vx: Any) -&gt; None:

    gui = g.app.gui
    ms = gui.find_widget_by_name(c, 'main_splitter')
    ss = gui.find_widget_by_name(c, 'secondary_splitter')
    lf = gui.find_widget_by_name(c, 'logFrame')
    edf = gui.find_widget_by_name(c, 'bodyFrame')

    init_orientation = ms.orientation()
    if init_orientation != Orientation.Horizontal:
        ms.setOrientation(Orientation.Horizontal)
    ss.setOrientation(Orientation.Vertical)

    ms.addWidget(lf)  # Temporarily to get body to be second
    ss.addWidget(edf)
    ss.addWidget(lf)

    h = c.hash()
    vrx = vx.controllers.get(h)

    if not vrx:
        vx.controllers[h] = vrx = vx.ViewRenderedController3(c)

    ms.addWidget(vrx)
    if vrx.isHidden():
        c.doCommandByName(cmd)

    ss.setSizes([100_000] * len(ss.sizes()))
    ms.setSizes([100_000] * len(ms.sizes()))

</t>
</tnodes>
</leo_file>

EKR

[Thomas Passin]

Not if both are enabled, which I sometimes do.  I envision the script reworked into a function whose argument specifies whether to use VR or VR3.  Then two commands could be created using that function, one for VR and one for VR3.

Actually there's still a bug about which version to use.  The fixed script is below.   All these scripts have a big problem, though. They don't play together and they are not reversible.  For example, Jacob's "quadrants" script adds a new splitter.  If you run one of these other layout scripts, that splitter hangs around with no widget because the other scripts don't know about it.  I'm going to start a new thread about how we might deal with this general problem.

"""Change layout to Gates # 3 "render-focused"."""
# ref: https://gist.github.com/gatesphere/82c9f67ca7b65d09e85208e0b2f7eca1#file-render-focused

from leo.core.leoQt import Orientation

import leo.plugins.viewrendered as vx
PLUGIN = 'VR3' if 'ed3' in vx.__name__ else 'VR'
if PLUGIN == 'VR3':
    Controller = vx.ViewRenderedController3
    cmd = 'vr3-show'
else:
    Controller = vx.ViewRenderedController
    cmd = 'vr-toggle'

gui = g.app.gui

ms = gui.find_widget_by_name(c, 'main_splitter')
ss = gui.find_widget_by_name(c, 'secondary_splitter')
lf = gui.find_widget_by_name(c, 'logFrame')
edf = gui.find_widget_by_name(c, 'bodyFrame')

init_orientation = ms.orientation()
if init_orientation != Orientation.Horizontal:
    ms.setOrientation(Orientation.Horizontal)
ss.setOrientation(Orientation.Vertical)

ms.addWidget(lf)  # Temporarily to get body to be second
ss.addWidget(edf)
ss.addWidget(lf)

h = c.hash()
vrx = vx.controllers.get(h)

if not vrx:

    vx.controllers[h] = vrx = Controller(c)

[Edward K. Ream]

On Fri, Jul 19, 2024 at 6:00 AM Edward K. Ream <edre...@gmail.com> wrote:

> Here is the dynamic version:

Heh. The dynamic version will work even if both VR and VR3 are running. At the top level, change "elif" to if:

pc = g.app.pluginsController
if pc.isLoaded('leo.plugins.viewrendered3'):
    cmd = 'vr3-show'
    import leo.plugins.viewrendered3 as vx
    switch_layout(cmd, vx)

if pc.isLoaded('leo.plugins.viewrendered'):
    cmd = 'vr-toggle'
    import leo.plugins.viewrendered as vx
    switch_layout(cmd, vx)

Edward

[Edward K. Ream]

On Fri, Jul 19, 2024 at 6:02 AM Thomas Passin <tbp1...@gmail.com> wrote:

>> Next, I'd like to replace the vx switch. Leo's plugins manager can tell us whether VR or VR3 is running.

> Not if both are enabled, which I sometimes do. 

Our emails crossed in the ether. My version works for me if both VR and VR3 are running.  Does it work for you?

Edward

[Thomas Passin]

It looks like it will ... pretty much the same ideas as my revised script.  But see the new thread I just started to discuss the fact the scripts like these don't play together and are not reversible.

[Edward K. Ream]

On Thu, Jul 18, 2024 at 8:50 PM Jacob Peck <gates...@gmail.com> wrote:

Here's my go at a `quadrants` layout:

It works for me, provided that VR is enabled. Next, I'll make it work with either VR or VR3 (or both).

Edward