Hi, we are still struggling with custom toolbars in Rhino 8 and don’t like the way Rhino saves changes to a toolbar. I work on two computers and have edited the same file from two computers, but for some reason the changes didn’t update properly when I opened it again on the first computer, so I think this has to do with how Rhino stores changes made to a toolbar. So I tried to close the toolbar, restart Rhino and open the toolbar again, but still the changes wasn’t correct.
So I made a duplicate of the toolbarfile (in explorer of course since Rhino still doesn’t have a save-as…) renamed it, closed the toolbar in Rhino, opened the duplicate and then it was OK.
Obviously this isn’t a solution neither we nor you can live with, but until you fix this we need a way to reset a toolbar. Is there a way to do that?
@Gijs can you take a look at this and also direct it to whom it concerns? @gustojunk adding you here too, since you are in the process of porting tools.
Since there is no per-toolbar reset command, other than resetting ALL the toolbars, including the default, the only way currently is to delete the changes manually. The changes to toolbars are located in %appdata%\McNeel\Rhinoceros\8.0\settings\Scheme__Default
where you will see “yourtoolbar*.xml”. Those files contain the changes, deleting that file restores it to the last save.
Yeah, this is really bad - I yelled about this a year ago maybe. To add: last time I checked, if you have several schemes (different languages, workspaces etc.), running Reset resets all of them to default as well.
Just in case anyone does this accidentally, you can save your rear end because Rhino does make a backup of the last config when resetting and you can restore that.
You got it right.
And since this is a simple thing to do manually it is also a simple thing to do from a script, so I strongly suggest you add a Reset option to each toolbar asap.
The entire SVG - toolbar mess has gone on for too long and really needs attention over R9 development IMO. If you don’t do it now you will probably inherit the mess going forward, and that is a scary thought…
Well… I’m not porting anything else until this gets fully resolved. I only have some customized toolbars, less than half-way updated to V8 on my desktop PC. I barely use Rhino on my laptop because this problem is holding me back from bringing my custom tools, which is what makes me productive.
I can’t even attempt to propagate this to my laptop until this gets fully resolved.
Forget what I said yesterday about thinking about starting to use V9 WIP. I can’t even think about doing that until this gets fully resolved.
So here we are again, McNeel choosing to leaving us out of WIP testing, same as they did in V8 WIP because they still are carrying massive technical debt in the custom workspace workflow.
IMO, nothing, and I mean absolutely nothing, should have more development and company priority than fixing this mess.
I don’t think McNeel understands this, or maybe they are choosing to pretend to not understanding it, no matter how many times over the years now, we have been saying it.
Gijs, very important questions:
have at least 8-10 of your team and McNeel tried to do this with their own very different custom toolbars?
If so, have they made complex custom toolbars? Or just tested with the toolbar equivalent of 2 cubes?
If not, why on earth they haven’t?
When I say we are getting tired of you all shipping untested software this is what I’m talking about.
The solution here seems pretty clear to me. Or am I confused?
(following is my personal opinion)
For V8 it’s a done deal - I wouldn’t count on anything (behavoir-wise) being fixed, they’re just trying to keep the house of cards from falling down. We’re already more than halfway through the release cycle.
For V9 I do not know what has been decided - if anything. The two choices seem to be either try to fix the system selectively or start over from scratch. Again, we’re pretty far into the WIP development cycle and this will obviously be a major breaking change either way.
Your scenario here:
Theoretically this should be able to work, even in V8 - assuming that the toolbar is in a custom .rui and not in default and that you “save the changes” by manually going into the Toolbar dialog, getting the .rui in the dropdown and hitting Save. That should save the current version to the .rui and eliminate the “delta” (differences, changes) .xml file that previously had all the ‘unsaved’ changes to the .rui. There do appear to be some bugs in that this does not happen correctly for all users, the delta file gets left behind.
What I don’t know here is how the second machine will interpret opening your just-saved .rui, because on that machine there is also a ‘delta’ .xml file for the .rui in its previous state from when last used on that machine.
This ‘delta’ system is the one card that is holding up the whole house right now. Pull that and everything falls down. It needs to be completely eliminated - at least as far as custom .rui’s are concerned. Changes to custom .rui’s need to be saved immediately in the .rui file - without having to hit save or anything. No ‘delta’ files for .rui’s.
If Default is to remain native (à la V8), than the ‘delta’ .xml file system will end up surviving for that - as there is no separate file to save to. IMHO, we should go back to V7-style .rui for everything including Default - it was much more robust, portable, reliable and predictable. But that’s just my opinion.
That’s an excellent point, Mitch. Thank you.So let me please rectify what I said to a another viable scenario:
I will stop waiting for further fixes in v8, and rather move straight to V9WIP if this is what’s required to get this fully resolved.
Yes! This is the stuff that has me paralyzed, and I don’t dare to even try to duplicate my workpace on a second PC.
Will I volunteer to try this and help to make sure it works? Yes, of course, but only after I know at least 10 people at McNeel, have done this extensively, and they have reached a point of being good enough to go bother customers for further testing.
Yes, that is exactly what I experience and thus wish for a “reset toolbar to .rui file” option on a per-toolbar basis.
I am sure I can make a python tool that does this, closes the toolbar and installs it again, but I don’t want to work around (and keep all this noise in my head) issues like this.
The minimal effort bug fix I can think of is that when ever we close a toolbar from the toolbar options page, we are prompted with a warning that there is a “delta file” for this toolbar (if that is true) and that this will be deleted. (And to avoid loosing the changes we need to save the toolbar first, and be asked if we want that to happen).
Then we can open it up again and have it automatically restored to it’s initial state.
AND we need a save as… (that merges delta together with the toolbar and that deletes the delta and closes the old toolbar and opens the new toolbar)
An even easier fix would be to just toss the delta system out… but I see that this could mess up Rhino 8 for other users.
The idea with delta stuff is good, it is just badly implemented.
I totally agree with you all. Today I was trying to solve a problem with a linked toolbar that wasn’t resizing properly. I was going to delete the related .xml file thinking that this would restore the toolbar behavior.
Before proceeding I gave a final check to the name of the .rui file that contains the toolbar collection… the file size was only 1KB…
I opened Rhino 8.0 and from the toolbar manager I saved the collection to the .rui file
I went back to the file manager and the .rui file became 980KB
If I deleted the .xml file would I lose everything? Probably… I assumed that once all Rhino sessions were closed the .rui file would be updated automatically… but that’s not the case.
Now, I’m keeping the toolbar that doesn’t resize if called as a link from a button
another thing i don’t like about the new toolbar manager is that, even after deleting some buttons, while creating a new toolbar (following the wizard procedure) some buttons that had been deleted in the past magically reappeared… why?
Would be better to have a “purge” command to remove everything that is not needed?
Also, all the buttons with double command (macro on left button and right button) are proposed as single buttons… one icon for the LMB command and another icon for the RMB command.
So, after creating the toolbar i had to recompose the left and right buttons into a single one to avoid double the icons…
My only solution to the case of a toolbar not behaving correctly was to make a new toolbar, remake the buttons from scratch and then delete the old one. This generally fixed stuff. But making the new toolbar I followed the procedure below…
That is the typical result of having created your toolbar buttons directly in the button editor (à la V7 and earlier). I don’t recommend this in V8. If you want a clean macro library and functioning toolbars my suggestion is to always create your macros/commands first directly in the Macro section (Macros command), THEN run the button wizard, and choose the macros you created from the library. It’s a bit longer to do, but you will have something more reliable, and Rhino will not create a bunch of unnamed or numbered macros as it does when you make buttons as you did in V7 and earlier.
Hi Mitch, what happens if someone did NOT follow that approach and instead started to copy buttons of any existing tool to have a placeholder button in which they later changed icon and command via button editor, and now they have a note of duplicate macros in their Macro library? like this:
Right now, you can’t… Being able to identify which macro is used by which button(s) and which are not associated with any button is one of the requests I and others have made quite awhile ago. Don’t know what’s possible for V8 here.
Feature requests (requested by multiple people like 8-10 years ago):
Make it possible to restore to default individual toolbar(s)! Not the whole interface, which destroys the entire customization…
A way to identify new custom icons and modified existing icons (add a highlight outline colour to them maybe? Or add a tiny triangle to the upper left corner, opposite of the bottom right corner reserved for accessing additional floating toolbars);
Ability to copy all custom and customized icons into a new toolbar with a single mouse click (OK, maybe 2-3 mouse clicks, but you get the idea). That will allow us export the custom icons at once for backup purposes, or simply to utilize a single custom toolbar. Then, the user could delete all custom icons from the default toolbars, while they are transferred to a dedicated custom toolbar.
Sounds overly complicated to me… Once you start going down the road to custom, you need to be willing to accept you are no longer in ‘default’ territory.
For #1 it was however sorta possible in V7 and earlier, you could simply delete the custom toolbar you wanted to ‘reset’ and reimport it from the default.rui.
For #2 that’s a huge amount of tracking/bookkeeping to have to do for not much return (IMO).
For #3 again IMO it’s better to use a custom .rui to store your custom tools, that way you can (more) easily back up and transfer.
Proposal #2 is closely related to the need to identify custom(ized) icons so that the user could find them in case that he or she does not remember them. I’m getting old and start to lose track on where I put custom macros as a RMB command, scripts etc. This is also related to proposal #3.
Agree.
Default.rui should be “read only” to avoid any problem installing update.
Too many times in the past I discovered that the standard toolbar won’t update due to custom changes so it’s better to keep the two things separate.
You are correct.
Working from V1.1 to V7.0 in a certain way and suddenly you have to change your approach as if you had changed programs… I know that the new approach is more tidy and efficient (in the perspective of having a single macro for multiple buttons copied to multiple bars, if you have to fix a bug you do it only once instead fixing all the cloned buttons), but when I need to make a new button similar to an existing one the old way vs the new one is like “one minute vs 10 minutes”… not impossible but quite frustrating…
Probably I’ll start a little bit of meditation “Ohmmmmm, Ohmmmmm…”
