So we develop this Plugin for our 50+ Rhino users to speed up our processes. We designed some simple custom toolbars (containers) and suffered through the mess that Rhino 8 was when it came to custom UI designs.
Today I open Rhino 9 and find the whole way the UI is customized to be modernized (as was promized and discussed in Detail with Callum some months ago). Great.
Only one thing I immediately find missing. We have one toolbar with, say, ten commands in three groups. Meant to be displayed vertically as Text Buttons. Between the groups we placed Separator lines that are showing fine in Rhino 8 but in Rhino 9 they disappeared. If I change the toolbar windows proportions to a completely horizontal orientation (all buttons in one row), then the seperators appear again. However, in vertical orientation (all buttons in on column), the separators are missing. But this is exactly where we need them.
Would be so great if this could be looked at and fixed. Thanks in advance guys, you rock!
Maybe it goes deeper. I found other toolbars (containers?) where the seperators appear without problem.
Generally it is the same mess that it was in Rhino 8. Containers and Toolbars are still a confusing nightmare. I spent two hours with your toolbar developer on a videocall and went through all the headaches. He admitted that toolbars on Rhino 8 are simply buggy beyond recovery and that McNeel messed up there. Also he said that I should wait for Rhino 9 as the Toolbar / Container system would be completely rewritten. Now it looks different but the structural problems underneath are still the same and worse. For the user there is zero chance to properly (let alone intuitively) understand whether he is dealing with a toolbar or with a container. containiers pop in and out of existence. toolbars don’t save their location and size on screen, containers do that. but then containers can not even be saved anymore? They can only be loaded from file that was generated in Rhino 8. The “where is my custom toolbar setup saved” question is not answered. It’s just that you can’t save containers anymore. So this is worse than Rhino 8. Many bugs fixed, I can see that, but the structure is as terrible as before and worse.
This is soo frustrating. I hoped we can roll out the plugin we developed for our company, if not in Rhino 8 then at least in Rhino 9 without headache. Now we are back to square one. I’m suffering here.
It’s definitely not back to square one. When we tried fixing the issues in Rhino 8, we ended up concluding that rewriting was the only way forward. This has been a huge task and it is expected that there are still things left to be tuned. But the code has become better maintainable with the rewrite, which means issues and bugs can be addressed much faster.
I’ll discuss this with @CallumSykes and get back to you.
I found RH-77892 Moving to a new computer complicated (Containers, Toolbars)
Brian hits the nail on the head. I hoped that Rhino 9 fundamentally replaces all of that by a simple and easy to understand solution. My not small frustration comes from waiting for nothing.
Thanks Gijs for moving over my other message to this chat. In there I listed three points. Let me continue this list here:
Changes I make to a toolbar via Shift+RMB (=Edit toolbar button) are changing the visible toolbar itself but are not visible in the rui toolbar that I can see (and edit) by using the toolbar command.
when toggled via -toolbar command on a macro then toolbar does not remember size and position. when toggled from insite toolbar command (by clicking on the lightbulb) then toolbar also does not remember size and position except sometimes. completely random, not repeatable.
when making the toolbar narrow then buttons disappear way too early. My buttons are icon AND text. Only the small >> icon remains. When I click there then suddenly the appearing pop up shows the toolbar with separators, almost correct. But the button texts are not the (new) button property name but the entry in Macros Menu (all from Button editor window).
Minor annoyance: Button Editor Image is correct in Light mode and something random in dark mode. When I click on the random icon there the svg editor already shows the correct icon, how weird. Just click ok and now the dark mode icon is correct as well. Clearly a bug.
In Rhino 8 I have a good Toolbar that I like. When I export the container there and then import it to Rhino 9 then the toolbar is not updated. Together with my button changes not appearing in toolbar>rui view mentioned earlier I simply can not edit toolbars anymore unless through the new awkward editing function in toolbar>rui. In the container (?) seems to exist a copy of the toolbar but not the actual toolbar as changes to the toolbar in the container are kept.
Worse. I tried to import the good container, it did not show. But now one of these corrupt RUI files appears in the list where it is the RUI file name plus a long GUID-style number right there in the name. This triggers a trauma response from Rhino8 as these corrupt ghost RUI files where a big problem then. It came with the container I tried to load and in it I can see the correct container buttons. If I turn that toolbar on via the lightbulb there the now visible actual toolbar is not the one I see in the rui file but the one from the original rui file.
I selected the zombie rui and clicked on file > close rui file. My original rui with good name disappeared instead. The zombie rui remained.
after reopening the good rui from file the lightbulb for my desired toolbar is grey and does not change status anymore. Only after closing and reopening via toolbar command it works again. Position of my desired toolbar has changed again but I have no control over that. It’s quite random.
Button Editor: changes of Properties Name are directly mirrored in Macros LMB Menu but not the other way around. Thats not simple or elegant. It fixes a problem that should have never existed in the first place.
The problem of point 4 disappeared so repeatability might be an issue there.
Escape does not work to cancel the RUI editor. would be nicer if that worked.
Oh. When in the RUI editor and turning on or off a toolbar via lightbulb then the toolbars position is to the left of the RUI editor and aligned with the editors top. Fancy but I could not care less. It should not do that. It should appear WHERE I WANT IT TO APPEAR! And stay there. If it shows off screen (happens on multi monitor systems) it can be invisible, I understand. But the solution should be something else and involve me being able to control the toolbar position and size permanantly and be able to save this and transfer it to other computers without breaking my fingers.
I want to be able to toggle toolbars on and off. via -toolbar t … t … _enter _enter that is possible. I notice that this creates a container with the same name as the toolbar that contains the toolbar. Good. However, the container disappears if I toggle the toolbar off with the same macro. Is this a bug or intentional? Half my problems would be solved if the container would stay in existence with its position and size but only become hidden (lightbulb off). Using the -container command lets me build a toggle for the container with the toolbar inside. However, here the toggle also deletes the container instead of turning it invisible (which would be the expected behaviour). This looks very much like a bug. If both toggle macros would not delete the container but just hide it then life would be much better.
I can use windowlayouts to save container locations. If containers dont get deleted unintentionally this would be the best way to transfer a UI setup. A problem here: if I update and save a layout, close the window , change some container positions etc, then open windowlayout and doubleclick on the desired layouts name then not the just saved version is restored but the one that was saved BEFORE this last one. So the second last gets restored. Only the next time doubleclick restores the correct layout. Clearly another bug.
Shift RMB should allow a toolbar button to be moved to any other toolbar. It does at the moment but earlier it did not work on some toolbars/containers but on others from the same RUI it did. It was very odd. I can’t replicate it at the moment.
When in the RUI editor and just inside a particular RUI all the available toolbars are visible. This view is VERY generous with screen real estate. Just a couple of Toolbars fill the a whole screen. There is so much unsused empty space here. Could this whole view be much more compact please so we have to scroll less? Again, currently eveything too large here. Toolbar name is above the list of buttons for example. Could be between lightbulb and frame with buttons for example, this would save a lot of space. between button frame and next toolbar name there is also a lot of nothing.
I need more information on this bug, can you show an example what this looks like? Do you see this only on your custom toolbar or also in the default toolbars? If only on the custom toolbar, then pls upload a sample rui
Since I cannot reproduce bug #4, I suspect this is at least somewhat related. I def. need to talk this through with @Callum.
Honestly, I think the Container export route is something we need to try to avoid, I am suspecting these issues (8-11) are a result of it.
Did you by any chance try OptionsMigrate instead to port over your Rhino 8 toolbars to Rhino 9?
Open to suggestions, but this works as designed. You might want to have different names for Menu and tooltip. If you don’t, just make all your edits to Properties > Name. It will keep the values equal as long as the started out the same.
If you have other suggestions, let us know. Maybe the Menu and Tooltip names should be locked (linked to Properties > Name) by default.
