How to keystroke toggle panel/toolbar visibility?

Rhino Rhino for Mac
1

I would like to toggle the display of various toolbars or panels with keystrokes only when I need them and keep my screen clean.

I skipped Rhino 7 but in Rhino 6 I could use a command alias like
“! _FloatPanel 6df55e69-e102-4a72-b181-11664046c93f Toggle” to toggle the LayerState toolbar just by repeating the alias.

I am finding that in Rhino 8 Mac the whole method is different and some panels/toolbars will toggle and some will not. It’s obvious that I am not understanding the change but I’m capable of learning.

I have created a separate window layout and removed the nested panels/toolbars from containers. So far I’m not a big fan of containers or panels right now with my limited understanding of their value. That might change if I find them useful.

I have been successful in toggling the following by using the command:

LayerStateManager toggles on but if I repeat the command it doesn’t toggle off. Dialog remains.

SnapShots toggle on and off by repeating the command.

NamedViews toggle on and off by repeating the command.

NamedCplane toggle on and off by repeating the command.

BlockDefinitions toggles on but not off. Dialog remains.

Textures toggles on but not off. Dialog remains.

Rendering toggles on but not off. Dialog remains.

Materials toggles on but not off. Dialog remains.

How do I toggle the Dimension toolbar on and off?

How do I toggle the Arc toolbar on and off?

How do I toggle the Box toolbar on and off?

How do I toggle the Align toolbar on and off?

I haven’t tried everything but these are the elements I use daily.
I’d appreciate any guidance.

2

hi @Maxedout
We just had a discussion about containers internally and found some inconsistencies between Mac and Windows how these work. @wim mentioned that you can toggle containers with a Macro, e.g. if you would make a container with one panel, and call that container Materials, then you should be able to toggle with:
-Containers Show Materials Toggle EnterEnd

The idea with containers is that you can create a certain toolset. Each container can contain multiple panels, and a panel can occur in multiple containers. For this reason, toggling the panels themselves seems to be a tricky concept in Rhino 8, and the above macro is a more consistent way forward if you want to be able to toggle panels individually.

Related to that are Window Layouts. Window Layouts can contain multiple containers, that together form your workspace.
So once you create new containers with each panel separately, you could save that as a new Window Layout.

For example, it would then look like this:

image
image780×1644 73.1 KB

See if this Window Layout works for you:
Separate Panels.rhw (212.3 KB)

3

@Gijs…

Thank you for your response but in your provided example it seems I would have to create individual containers for each single toolbar I use and then toggle them when the need arises. It also means that if the syntax of container use changes I may be faced with revisiting all my customizations again and again. Why not just toggle the toolbar?

Or are “panels” a rename for what used to be toolbars in V6?

Also I have experimented with the window layouts and have created one with multiple Toolbars/Panels visible but again I’m a believer in having the pertinent tools visible when needed and stored when not. My current process is very methodical and I may be unique. I do a specific function or set of functions at a specific point in my workflow thereby ensuring consistency for my client. If I’m doing design work for myself I can be more flexible when it comes to searching for things.

From what I discern containers provide a way to “nest” more than one panel/toolbar? thereby requiring additional picks to accomplish the same as having a single toolbar appear when you need it. I may have missed a lot of this when I went from V6 to V8 skipping V7.
Another thing that seems counter productive is that nesting multiple “panels” sometimes results in a flyout arrow to display additional nested panels/toolbars whatever… More clicks and interpretation of icons…

I’m at a loss to where this is better than just toggling a pertinent toolbar on, execute the command, toggle it back off, screen uncluttered. I’m also confused as to the benefit (productivity wise) of containers and panels. To me they just add additional delays and clicks to get my work done. If I have a way to just toggle the visibility of each toolbar similar to V6 and let those that want to adopt the containers/panels logic continue on their own way.

I’m all for change when it either improves my user experience or speeds up my work processes. Additional mouse clicks do neither.

This whole container/panel/toobar complexity still confuses me. What used to be functional with toolbars seems to now be 3 levels more complex.

Please don’t interpret this as whining, being difficult, or being confrontational as I am not. I will adjust my work flow to whatever it takes to continue to make money but it would be easier for my brain to accept this “improvement” if I understood the reasoning or benefit.

If it can’t be done please let me know and that is fine. I will devise a suitable workaround.

Thanks

4

The way it has been on Mac before is a bigger change to how it’s been on Windows.
But I think we can find a way to make this better and still keep the container concept. Currently, as you noticed, some panels open up a container that contains multiple panels. In the default Window Layout, there are now containers that should not be there which causes this, and this is on the list to be fixed.

When that is changed, I think you can still open up individual panels the way you are used to, (and they will pop up in their own container) and for the ones that don’t work, it simply means that they need to be fixed. What I find important is that things behave in a consistent manner. So if one panel can be toggled by running the command (e.g. Materials) then it should work the same for other panels.

So suggested is that it would work like this (and it already partly does):

-if a panel is in a container (as a tab), running the command brings it forward
-if a panel is present in more than one visible container, running the command will bring forward the tab in the container it was added to last.
-if a panel is not in a visible container, running the command opens it up in it’s own floating container
-panels that are opened in said floating containers can be closed by running the command again, this we need to get consistent across all panels.

Let me know if that sounds right to you.

5

@Gijs…

I appreciate you revisiting this. And as always. McNeel folks are the most approachable in the industry and I thank you.

First I’d like to pass on my interpretation of the definition of Toolbars/Panels/ and Containers. I may be wrong but I’m trying to take things to my least complex level.

Toolbars:

An object that houses a single or array of simple command icons (including custom). Additional arguments for each icon will/may show up in the command line if applicable. ToolBars themselves float within the design window (unless containerized).

Panels:

An object that houses a more complex command and provides all the arguments/options for said command within the object proper. User can preload a number of arguments prior to executing. Panels themselves float within the design window (unless containerized).

Containers:

An object that provides a mechanism to assemble both toolbars and panels within the object. This permits the composition of what you referred to as a “ToolSet”. One additional characteristic of a container not prevalent in Toolbars or Panels is the ability to dock at strategic “hot” areas around the working screen.

Please correct me if I have my crude definitions wrong.

Now on to your suggestions (you asked me if things sound right). A lot of my comments refer to Panels but I would expect them to apply to Toolbars in exactly the same fashion.

“-if a panel is in a container (as a tab), running the command brings it forward”

If I already know the command that will bring the panel to the front in some container, why not just show the panel I want and forgo the need for me to move my focus to a container? Especially if the desired Panel is in multiple docked containers on the screen. Personally I don’t care where it is, I just want it to appear so I can use it and go away when I don’t need it.

“-if a panel is present in more than one visible container, running the command will bring forward the tab in the container it was added to last.”

In addition to my above comment an edit to an existing docked container to add said panel will cause the panel to now show up at a different location (last “added to” container will gain focus). Then things become a game of “Panel, Panel where is my panel”? Why not just show the panel requested and make things simple?

“-if a panel is not in a visible container, running the command opens it up in it’s own floating container”

Why force the container when the panel exists as an independent object? Especially if I already can turn it on just by typing a command. Ie. “LayerStateManager” displays the panel without a container as far as I see. It just won’t go away if I repeat the command.

“-panels that are opened in said floating containers can be closed by running the command again, this we need to get consistent across all panels.”

Wouldn’t it be far more simple to just repeat the command and the Panel hides itself? Selecting the “close” icon upper left already does this but requires mouse movement. Not everyone needs everything on the screen at once but I may be wrong. There are a lot of keyboard wizards that hardly ever use icons and probably could care about Icons and their complexity. I’m not one BTW.

I am 100 percent in agreement with consistency across the platform. If some code based dependency on containers was implemented then why not just put everything within containers and code in a characteristic that containers can have nested containers? In my mind this would simplify things.

A container could be a tool bar with simple command icons and a name. It could be a panel with more complexity and a name. It could also permit nesting of other containers. After all, toolbars and panels are at their root “Containers” for stuff.

I can’t see where my thoughts will change anything for those that have adopted the use of Containers/Panels/Toolbars but if it does, I apologize up front.

Whatever you folks implement I will adapt and make work. I just need to know the guidelines before I spend a lot of time modifying my workflow. There are a tremendous amount of frustrated (and hostile) comments out there and I don’t want to add to that chatter. I also don’t want to take away your focus on “bugs/anomolies” that are actually causing people to lose money.

Thanks,

D.

6

this is not entirely correct, once you drag out a toolbar, it will create a container with one toolbar. Any item in fact that is shown, whether docked or not, is displayed inside a container.

The idea is that running the command indeed brings the panel in vision. My proposal means that when the panel is already on screen (as a tab in a container, but not visible) it will bring it to the front. If you only want panels visible when you run a command, you can still do this in my proposal. In that case, don’t place it as a tab in any (docked) container.

Maybe you are right, that to keep things simpler, running the command should just pop up the panel (it will always pop up in a container though, but that shouldn’t matter). On the other hand, if you have a dense Window Layout, and you are unsure about the icon of a panel, or just lost, but know the name of the panel you are looking for, having it brought forward by the command can be helpful as well. This way your workspace stays the same.

I don’t want to close panels/tabs in containers that are not floating, since that can mess up a Window Layout. This is why I would only want floating panels (containers with one panel) to close upon rerunning the panel name.

I’ve logged the proposal as RH-79688 Proposal for Behavior of panels

that doesn’t mean this is now set in stone, your feedback is highly appreciated.

7

Thanks Gijs,

I can appreciate the closing of a panel messing up a window layout and I didn’t consider that.

So you are saying that if I choose Window->Toolbars and toggle the “Align and Distribute” toolbar it appears within a Container? I was misinterpreting the toolbar nomenclature and assumed that the container shown was indeed the old V6 toolbar.
I now see if I use the Containers->“Align and Distribute” choice I get the same visible result.

Why would one create toolbars and not just move to containers for everything (for my information only)? Seems redundant.

I understand your suggestion for “containerizing” each toolbar and just calling it out by name as a suitable solution and it would work. I don’t intend on heavy use of containers so it is a creative suggestion. I just wanted to make sure if I go through the effort of encapsulating each toolbar I use within a container that I’m not wasting my time as things evolve.

I’m not sure my thoughts denote a logged “RH” but thank you anyhow.

8

If that logged YT will be implemented, I think you don’t need to make your own containers at all. It will simply mean what you previously did with FloatPanel (Which was a Mac only command btw) should then be possible by just running the Panel name / command.