Rhino 8 toolbar behaviour

that option is not available in Rhino 8 currently, and I hope we get it back soon, especially for Mac since it was the default there to cascade as menu

(https://mcneel.myjetbrains.com/youtrack/issue/RH-78667) was logged as a wish by Dale due to a post I made. But i believe there is a misunderstanding:

I was not wishing, I was pointing out a grave regression.

It is not specifically about having a menu INSTEAD of a Toolbar, but rather, the issue is about :

A) Having the toolbar viewed as a list with icons - this is yet only possible by resetting each individual toolbar by floating it, and then right-clicking the top of the toolbar to open properties…

  • having a global setting would be better

B) The toolbars should work SIMILAR to previous RH7 menues:
MEANING: Left click-hold mouse-over will fly-out sub-toolbars, and open the desired tool by release-click.
in total just one click would surf through the entire toolbar and sub-toolbar.

in RH8 one has to click two or three times to open to a desired sub-tool, AND you have to do it with very distracting info pup-ups, AND be able to hit the small corner arrows to cascade the sub-tool bars. This is tedious and counter productive, compared to previous versions.

AND … by the way … IF one click-opens the wrong sub-toolbar by mistake… Have you noticed how it is not really possible to click-close that sub toolbar again? One has to either click-close the entire toolbar and sub toolbar by clicking outside the toolbar, OR find another sub-toolbar to click open, because the one you where going after in the first time is now hidden behind the wrong sub-toolbar…
but if you click on another sub-toolbar, that closes the main tool-bar, and leaves only the second sub-toolbar open. … Its a mess. I end up clicking 5-6 times if that happens…

3 Likes

Yes. Very well put. Especially the note about the interaction of click to open dropdown and selection by release

2 Likes

1 Like

Well, not quite, in Rhino 7 for Mac, toolbars by default cascade as menus, and it’s not the same as setting a toolbar to icons and text.
FYI: The item is marked as regression

I think if this option comes back it should solve most of the issues you now encounter with the numerous clicks. You can try this out: by making a toolbar small until it shows >>, then the rest of the tools will cascade as menu, and behave almost the same as they did in Rhino 7 for Mac. As mentioned in the YT, that was optional in Rhino for Windows.

As for selection on release, that’s a separate issue, I assume you mean by that:
RH-73900 Extra click needed to acces a command in a flyout toolbar

For me, it is.
I really hate how McNeel have replaced MacOS menus with unusable custom pc-like UI items, which are at the same time ugly, buggy, slow, big, and again ugly and freaking buggy.
It’s very clear, at this point, that McNeel isn’t capable of dealing with UI: if they stick with their custom-made horrible fake-cascade toolbars/menus, there will always be tears.
Having standard MacOS menus back is the only solution, unless they hire some competent designers.

Thanks, Maybe you could elaborate on the more specific difference you are referring to ?
Are you talking about code or taxonomy ?

I was trying to be accommodating towards the choices McNeel has made with RH8.
I guess I , and other users that are trying to describe the same issues, am talking about how the UI feels to work with in RH7, and are suggesting ways to get back to that same flow and efficiency with what we got now in RH8, given McNeel has chosen to re-write the entire code.

Most people are not trained to express those day to day user experiences into specific code and programming language, and if there is a problem to convey even the most simple gestures with the mouse, and it has to be technically split up into the tiniest fractions and actions to be precisely described and understood by a programmer / developer, what we are talking about ( like what is a mouse-over, a left-click-hold, a click-release etc and discern the technical differences between a menu and a toolbar listed view) then this feedback process is going to be a very uphill experience for us as users.

1 Like

All that would be true if McNeel had a Mac UI dedicated team. Which is not the case, unfortunately.
So, every chatting is completely useless. The only solution, if McNeel doesn’t want to put money on a competent team, is to ask for coming back to good simple, working and effective MacOS GUI. Cascade menus (and menus in general, for god’s sake!!), toolbars, etc.

Hey Andrea :slight_smile: If you go down that road by keeping the old RH7 code base for the UI, you will still have a seperate Mac and PC platform, which is the very thing McNeel are NOT interested in anymore. Two sets of platforms and design generates way too many other issues with dual documentation, training material , difficulties for cross platform users etc.
I personally agree with heading towards a unified platform, and ironing down the issues to get there. Thats why I suggest to work with whats there in RH8 and just ask McNeel to be well aware of the small details on fx this current issue, how important it is to keep the elegant workflow and functionality intact, only with a new platform. I would ask you be a bit more coorperative towards the overall goal, despite being frustrated, that would help things along

2 Likes

Me too.

Yeah…

I just mention it because I want to make sure we talk about the same thing, that’s all.
In Rhino 7 for Mac, the toolbars cascade as Menus by default. In Rhino 7 for Windows, they cascade as Toolbars with icons by default.
What I would like to get back is the cascading menus. The Icon and text toolbars are in most cases way too big to be useful, at least for a default.
Additionally, the menus don’t need the extra click for additional cascading menus.

but does it really matter if it is menus or toolbars ?

From what I have learned recently, the Windows toolbars in RH7 also spring-open by click-hold / mouse over.

So the culprit in RH8 could be narrowed down to that specific missing feature: click-hold / mouse over spring open action.

I mean, if one can customize the toolbars to a list view with icons, i suppose whats only missing is to have a decent size of icons, a mouse-click hold and mouse-over action to spring open toolbars and sub-toolbars, and then select on click release.
And also place the spring opened toolbars to the side, so that one can keep visual overview of everything.

This way bot Mac and PC users get what they are used to . (or at least really close, in terms of mouse clicks and performance)

I have been told the the chosen code platform , EVO, does not permit a mouse-click hold and mouse - over spring open action… ?

I may say, if that is really true, i would argue this choice of code platform was not really well thought through… ? :wink:

that part is mostly what is happening in a cascading menu, and it is still there, it just needs to be enabled for the first click on toolbar button that has a linked toolbar. The difference with Rhino 7 is that you don’t need to hold the left mouse to browse for the tool you want. It has it’s ergonomic advantages
Again, try making a toolbar small enough so that >> appears. That’s the cascading menu that should be allowed on a button that has a linked toolbar:

that as you know, is currently not possible, but listed as a bug.

It looks like the diminished panel defaults to MacOS own menu system ? isnt it ?

I count 4-5 clicks with this suggestion :
#1 to open main panel
#2 to drag out to floating, diminished size
#3 to click-hold to spring open MacOS menu, and release-click to select
#4 to close diminished panel
#5 ups, another click to close, because it wasnt clear where the tiny red button was…

Im sorry this doesnt feel suitable for my usual workflow, but maybe the developers could use this as a workaround (default to Windows or MacOS menues?)
Am I doing it right as you suggested ?

I think you misunderstood why I posted it, it is not meant as a workaround, nor a solution to this problem. It’s just to show that the menus are still there, and that that is what I want to get back, and I suppose you too.

ahh… cool :slight_smile: ok so the functionality is still there, in the code somehow ?

(remind you , I am not a coder, developer etc, I just asked / googled what the correct terms for mouse action is… hehe)

ok, but will the cascaded menues work with the plan of unified UI (Windows/MacOS ?)

What I showed in that video works exactly the same on Win and Mac.

cool ! I get your point now.