Hi RMA team,
This has been bugging me for a few years for now. I’ve come here for help and followed all the advice I’ve received, and the workarounds that I can, and I still cannot find a solution that easy to live with.
I’ve spend a lot of time to capture as well as I could the entire problem. Tesha took me a few hours of work, so please take a close look at it.
Let me explain the problem:
You McNeel, create default toolbars, and any new tools you build (like during the WIP) show up in updates every once in a while in these default.rui files, in theory…
…In practice, many times these new tools/buttons do not show up, so your workaround for that is having us run _ResetToolbars. Which is a very destructive command since it will manage to force bringing-in all your updates to the toolbars, by also wiping out all my updates to such toolbars. I should not be making updates/changes to default you might think… well, you kind of force me to do it. Let me explain more.
I want to see, and use all your updates, but I also have more advanced work to do, and for that I need my own toolbars/tools (many of them created by your super supportive team or the amazing folks in this community). So I have custom variants to toolbars like ‘Main’ (called G_Main) and ‘Standard’ (called G_Standard), but I still need to be able to see your ‘Main’ and your ‘Standard’ toolbars. Why? Because I work with a team, I need to show/teach them things sometimes, so I have to go to ‘default mode’, to make sure that I show things are in a familiar environment. This is the same problem any team lead, educator, trainer, support person would also have. So this is not a weird edge case. This is a very common case for any power user who socializes such power usage.
Let me build up how the problems start…
Step 1. As long as I keep all my tools in different parts of the screen from your tools, it’s all good> Like here:
Step 2. Let the trouble start. Now to be able to collocate my G_Main and my G_Standard in the same screen space/group of tabs as the default tools, Rhino actually makes disassociated/unlinked copies of those toolbars. Or what I called ‘unsecured’ copies, since they will vanish the minute I have to run _ResetToolbars again, which is the workaround to see your updates on toolbars.
Step 3. This is the result of such a destructive move:
Step 4. This also creates a lot more problems. If my tools (buttons) in my custom toolbars where linking to other [copies of] default toolbars, when I drag them over I will also be dragging over copies of those linked toolbars:
that eventually I have to go and purge one by one, very carefully, so I do not create more destructive damage.I walk you through this messy process in this video:
In this video as I documented all these problems, I realized that I encountered a new ever crazier reliability problem: Rhino is somehow cashing older versions of my copied toolbars!
To see for yourself what I just showed here in video 02:
Want to see the bait and switch? Go pack to video 01 and look at 1min 25sec of where I first load these toolbars and pay attention to the shading icons on ‘Standard’, and the group/cap/extract surface icons on ‘Main’. Then in 02min 47sec you will see some of those icons are different. I also captured it here:
Also let me remind you that every time I have to make a change to my G_Main or my G_Standard I cannot do it to the ones that I’m actually seeing on my screen and using, because those are disposable copies! Instead I have to do the following:
- I have to go back to ‘show toolbar’ and show the ‘archival version’ in my custom workspace
- Make the changes there
- Go back to default and delete my copies of G_Main and G_Standard
- Drag over again my G_Main and G_Standard to the Defaulr.RUI groups.
- Go back to Tools>Toolbar Layout>Default and hunt for all the ‘toolbar 00’ and ‘toolbars 01’ that I had been re-copying over as linked toolbars.
IN SUMMARY
This is a complete mess. This is not a good way to manage the complexity of all the problems you have built and all the workarounds of each of those problems you have also come up with.
I see the following problems that devolve into more problems:
Problem 1: Rhino updates cannot deliver us reliably new toolbars/tools in Default.RUI without running the super destructive _ResetToolbars (which BTW it closes all other working/open toolbar files, which makes no sense to me).
Problem 2: you do not let a toolbar group contain referenced (instead of dumb copies) of toolbars from other custom.RUI files.
Problem 3: if a custom toolbar has linked toolbars that are exact replicas in content and naming of toolbars existing in Default.RUI, you don’t even parse them and compare them, so simply add copies with suffixes 00, 01, 02…
Problem 4: The new one I’ve discovered recording this: You cannot even reliably copy a toolbar from one .RUI file to another!
This is all very sloppy work, that has been patched over and over in Windows for the last 20 years, don’t even get me started about the spacing and snapping behavior of them, or the icon management approach. I think for now at least you should try to make living with a “Default +” workspace a little bit easier for us, especially considering this is the most likely scenario of usage for any team lead, trainer, or educator. These are the people that help you grow your business more than anyone else, so please give it the attention it deserves.
Thanks,
Gustavo







