There’s been a lot of questions about Rhino 8, it’s new User Interface (UI) system, and how to migrate existing tools to it.
I’ve started putting together a guide that discusses the new Rhino UI system for Rhino 8 and how it differs from that of Rhino 7 for Windows. You can find the guide here.
Feel free to point out any mistakes or confusions you might run into.
Also, we’ve see a number of questions about how to load or close toolbars, like you would if you were running Rhino 7. Hopefully the above guide will help with these.
As of today, the toolset available in RhinoCommon to manipulate the new Rhino UI system is incomplete. We’re working hard to add the additional Rhino UI classes, properties, and methods required by developers. (RH-78479)
I have just now posted my concerns on the toolbar menu logic in RH8. You seem to be the right person to show my little video in this post, and ask the pertaining questions, regarding the menu logic in those RH8 toolbar menues (or button containers, as it may seem they really are now)
Note that I am not criticizing all efforts to make Rhino UI customisable or unifying PC and Mac versions to one similar UI at all. Cudos for such efforts.
I just find the missing “mouse over > fly out submenu” option critically missing.
We have guides on Rhino - Creating and Deploying Plugin Toolbars (rhino3d.com). That 's good.
However The “rui” file seems not have support on “Options - Appearance - Colors”, I mean we can’t use different image for different colors with rui file. When I edit the button to use different image on different RH8 appearance color, no changes apply to my rui file, the changes are applied to a xxx.xml file in “…/settings/Scheme_Default” directory.
You can provide different images for dark and light mode
that’s (still) true today (4th of June 2024) but the ultimate goal is that this will be solved to always save to the rui and not use the xml for custom rui files. But we’re not there yet.
For now, changes you make will be saved to the rui file only when you explicitly save the rui file.
We don’t recommend using the rhc file for deploying toolbars, in fact these .rhc might be depricated at some point.
Hi,
I have created my plugin Toolbar - saved it as an RUI file.
However, if I try and modify it, even export the modified RUI, it doesn’t get updated more than once.
Anything that I am missing?
I can see from the Windows Explorer that the XML file is getting updated. But how can I export it as RUI?
Windows 10 (10.0.19045 SR0.0) or greater (Physical RAM: 32GB)
.NET 7.0.0
Computer platform: DESKTOP
Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce GTX 1050 Ti (NVidia) Memory: 4GB, Driver date: 6-8-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 536.23
> Accelerated graphics device with 4 adapter port(s)
- Secondary monitor attached to adapter port #0
- Windows Main Display attached to adapter port #1
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)
Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High
Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 6-8-2023
Driver Version: 31.0.15.3623
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 4 GB
Rhino plugins that do not ship with Rhino
D:\Maya\TiaraCAD.rhp “TiaraCAD” 0.0.2.0
@maya_puundale to avoid confusion, can you tell me exactly what and how you are modifying the toolbar before you attempt to save it? And can you send me the RUI file and the xml file that gets the changes?
Thank you for your replay, Gijs.
Yesterday, I tried to deploy my toolbar again. And it seemed to be a success.
And I want to explain my past confusion here. The confusion is about difference on UI System between RH7 and RH8. When we edit toolbar in RH7, we get our rui file modified; meanwhile, when edit in RH8, we get some xml modified. Therefore in RH8 we have to explicitly export the rui file using “Export RUI File…” from “Tools” menu. In RH7 we just copy or saveas the rui file.
However, there is a situation still error-prone that user somehow edit the toolbar and get some xml generated by RH8 locally, when user upgrade the plugin, the new toolbar from new plugin release may not work well.
Well, the idea is that the xml files are going to stay in use for the default toolbar, but also for plugin toolbars. So when you change custom RUI files, changes should only be added to those RUI files eventually, when
RH-80791 Don’t save diff files for custom RUI files
gets fixed. But once you deploy it as part of a plugin, changes a user makes, are not saved into the plugin RUI. This means that any changes you push will show up at the users’ end. For example, if you have a toolbar with 5 buttons, and the user adds another to it, your 5 should still update, and the change by the user is kept.
Only when the user decides to reset their toolbar customizations, the toolbar will be reset to the original toolbar / the one you pushed in the update.
Reset do solve the question. However, reset command do not support reset a particular toolbar from plugin. It just reset all rhino toolbar. Sometimes, it 's unacceptable.
I am so happy to have found this thread… spherene is releasing our plugin today for commercial use and we deploy the toolbar that comes with the plugin as separate, downloadable file since the packaging manager distribution lead to confusion.
Now we had some beta customers telling us that in Rhino8 (Win and MacOS) they can not install the toolbar by hand. I have tried to recreate the behavior without success and was not sure if it was user error using the new toolbar window in RH8. Today I gave it another shot to break the toolbar installation and found 2 bugs.
Now you see that it is impossible to have the toolbar entry with the checkbox back.
Even when you File/Close the spherene_RH8 in the dropdown, next time you File/Open the RUI it shows up without the checkbox’able toolbar entry.
Bug 2, the reset issue (Thanks for this hint in this thread!!!):
To solve the toolbar installation
Now you loose not only custom toolbars but also UI color customization (I had a dark background before), even with only the one checkbox for the toolbar reset. This seems to be a bug.
Conclusion:
This is is a hacky solution and not good for our customers because they loose more settings than wanted but it seems that this is the only way to get imported toolbars working again if they behave strange as stated above.
As this seems to be a fairly big issue with lots of confusion for customers I hope both behaviors can be fixed soon ;
