Ah you’d like your floating containers with a single tab, to not display this tab at all?
Yes, exactly. When the container has only one tab, I would like to hide the tab completely to keep the UI cleaner.
It’s a good idea, logged here → RH-94845 Hide tabs of floating containers when only 1 tab exists
@RedAlert in your screenshot example how would you close that toolbar or dock it in the top container as a tab?
Hi @Gijs
The tab auto-hides after docking, but doesn’t disappear completely—it reappears on hover or movement. I was mulling it over like this 
@RedAlert in your screenshot the toolbar has no close button, nor a title. A toolbar lives inside a container. The container can be docked or the toolbar itself can be moved to another container by grabbing its tab. I want to prevent that we create a ui where moving your mouse over the edge of a container pops things in and out. If anything, it should look like the toolbars on Rhino 7 for Mac.
RH-92327 Toolbars: Double-clicking toolbar shows ultra-wide textfield
Hi @CallumSykes,
Are we going to see the following features as this progresses?
- An option to duplicate an existing RUI to form the basis of a new one. Saving the RUI file under a new name doesn’t work because the new file has the same uid as the old one.
- An option to copy an entire toolbar from one RUI to another. Opening one RUI, selecting a toolbar, hitting Copy, opening another RUI and hitting Paste doesn’t work because nothing gets pasted.
- An option to copy a toolbar within a RUI. Opening a RUI, selecting a toolbar, hitting Copy and hitting Paste doesn’t work because nothing gets pasted. [EDIT: a copy did get pasted but did not show up until the Toolbar window was closed and re-opened.]
- An option to delete a divider from a toolbar. You can add but there is no way to delete.
- An option to reorder buttons on a toolbar. At the moment there is no way to drag or shuffle icons left or right so if you want to place a button from the All Buttons table anywhere other than at the right end of the list, you have to use the Insert New Button option to place an empty button and then fill out all the details for it by hand, then delete the good button that was in the wrong place.
- A visible indication that a button has properties that have not been filled in.
- A visible distinction between buttons that have the default McNeel properties for those buttons and those that have been added or modified.
- A search and/or filter mechanism for the All Buttons table.
And can thought be given to the following:
- Can it be made more obvious that Cancel instantly closes the entire Toolbar panel and doesn’t just take you back one step?
- Adding existing buttons to a toolbar propagates duplicate buttons in the All Buttons table.
- The Existing Icon panel shows a different sequence of icons from the All Buttons list (for example there is a 3-D Digitizing icon between 3 viewports and 4 viewports icons in the former but not in the latter).
- Dark icons are not handled by the Existing Icon mechanism.
- The Toolbar panel disappears whenever Rhino loses focus and reappears when you click on the canvas. The Existing Icons panel remains visible throughout.
Enough for now, coffee is calling.
Wow @jeremy5 !
I love this huge list, thank you so much for taking the time to write all of this.
- SaveAs will give everything in the file new IDs, so that might be your best option.
- A bug! It does seem to work if you select something. YT → RH-94849 Copying a toolbar from one RUI to another does not work
- More copy bugs, it should do, it does immediately for me on Win/Mac. I’ll have to try an older version to see if it’s that.
- Great catch, hadn’t spotted this. YT → RH-94850 Cannot delete a divider in the Toolbar Editor
- You can use shift to drag things (same as outside of it). Maybe I should write a label saying that.
- Can you expand on this? Would you like the text areas to maybe show as red or something?
- Hmm. I’ll have to think about how to do this, I’ve seen it requested and it is possible.
- Top Right search works here, I’ve gotten feedback this isn’t obvious so I’m going to improve this.
And regarding your 2nd list
- I’ve gotten feedback about this too, will be considering how to make this more obvious.
- Hmmm, it shouldn’t do that because they should be “equal”, it takes every toolbar item and compares for equality.
- I should order it by name. It has more icons in it of course, it has toolbar icons as well as item icons.
- If you use an existing icon the icon will use the light/dark automatically. The Dark + is only needed. If you’re seeing different I’ll need to test some more.
- Ah yes, it will do … Ok good spot!
I’ll try to make sure all of these are in not next Tuesday (because they need testing!), but the week afters build!
hi @CallumSykes,
Great work on the migration and new toolbar system so far. I know we have been chatting privately but I’m posting here on this thread some more general issues/bugs so your team can file them for you.
Two issues to report in this post:
1.Where did the ‘float to top’ go?
2. clicking OK in any open button editor hides all my opened/docked toolbars
See video showing both:
Thanks,
G
A much more frequent and useful application of the ‘float to top’ is to have always access to the most frequently used tool in a linked toolbar.
For example the default mode of the linked toolbar of analysis show the “_ShowDir” icon:
But in my case (and probably for most people) the most used tool is “_ShowEdges”, so if that linked toolbar had a ‘float to top’ you would have '‘showedges’ or whichever is the tool from that toolbar that you used the most, the one that’s accesible without even opening the toolbar. So the main toolbar will look like this:
Also, overtime all your tools from a linked toolbar would buble to the top of your main toolbars so eventually you would have a better grasp of their grouping and where they are.
G
Hmmm. I’ll have to research how this could be possible.
I believe these copy issues are fixed in todays WIP - RH-94818 Toolbar (New): Buttons are usually copied to current toolbar
Grasshopper_Gold_Test.rui (8.2 MB)
There are some really unpleasant issues with the Rhino 9 toolbar right now.
The group isn’t loading!
After restarting Rhino9 The icons are shifted one position (-1 index) to the left, which does not match the commands. !
This is the same issue for macOS Rhino9
I meant to reply and say that I’m looking into this
@CallumSykes this is absolutely good for experienced user but could be an issue for beginners who look around for tools hidden somewhere. The option should stay but to me not as default behavior.
I agree that showedges should be first instead of direction.
This is off by default as it has always been 