Starting from scratch here, will post the questions/comments as I go along…
I created a new blank scheme - so starting with completely default. Went to Window>Containers>Manage containers, and in there, I unchecked everything. However, the left “sidebar” remains as it’s not in the list…
And, If I uncheck it directly from the Containers dropdown list, I can’t reopen it either from Manage Containers.
I assume this is an “oversight” - Rhinoceros Sidebar should also show up in the “Manage Containers” list… or what?
Why is this a problem?
My intention is to build a completely new workspace independent of the default library, because the default library can no longer be removed and which any changes made to it are vulnerable if one has to do a reset. The way I have chosen to do this is to export the default library as an .rui under a new name, close all the default containers and then open the .rui and start modifying them.
When I do that the only way to get the “Rhinoceros Sidebar” back is to re-check it in the Window>Containers dropdown. But what have I done? Opened the one in default or the one in my newly imported .rui?
Next problem - related to above.
If I open Windows>Containers>Manage Containers, it always opens with “default” on top in the library dropdown. This sucks because I don’t want to modify the default library, I want to modify my custom one. Even if my custom library was active when I closed the dialog, default is always on top the next time I open it, I always have to switch back.
So, looks like this whole toolbar system is simply designed to keep people from doing what they want.
The Rhino philosophy has virtually always been “Change Rhino to work the way you want it to” and not “You have to work the way we think you should.” I have now run into the wall of the second statement.
So, thinking that I could create a completely independent workspace, I exported the default library as an .rui (named differently) and re-imported it. I then closed all the default library containers and tried opening just one of the containers in my re-imported .rui - of course, they are named the same as the default ones because I haven’t modified anything yet.
So, with my custom library showing in the dropdown, I tried opening “Main”, shows checked in the window and the toolbar is shown. Then to check, I look under default. Main is also checked!! So what did I just do? Does the “Main” container I have open exist in default or in my custom library? It contains which toolbar in which library?
I also decided to add a button to Main to see what happens (OMG, the “wizard” that one now has to go through for creating buttons) and, yes, of course, the button appears in Main no matter if I have the default library or my custom one.
So, lastly, I decided to delete the container “Main” (knowing that this would likely not go well…) - and of course, Main is now gone everywhere, not just in my custom library but also in default. So now a reset will be necessary to bring it back. At first I checked just “Restore default window layout” - that showed all the default tools but did not bring back “Main”. So then I also checked “Delete toolbar customizations”. That required a restart and then “Main” was back, but of course my previously imported custom library was also gone from the list…
Now, assuming that containers are not actually objects that are associated with a library, but are rather global objects above and beyond the scope of any mere library…
First, with nothing left to lose, I simply deleted ALL the containers in the “Default window layout”. this left me with no containers, but of course if I go to Window Layouts > Default Window Layout then a few (but not all) of them come back…
OK, delete them all again, import my previously made .rui and of course there are all the containers again. So somehow the containers are part of the .rui - but not really as they are also references stuff in default.
So, closed that and deleted all the containers so that there were none at all. Then I created a new .rui - completely blank, nothing in it. With that in the dropdown, I created a new container also from scratch. And, instead of choosing an existing toolbar to put in it, I made a new one. Then I copied a couple of buttons from default across. So I have a new library (not default) with a new container (not default) and a new toolbar (not default). But I really don’t know how to save all this so it can’t be destroyed; also there were so many steps and so many different places to go involved that I will never do it.
So again, giving up here for now, the whole system just seems set up to make procedures sufficiently complicated that virtually nobody will use them. I am simply trying to find a procedure whereby one can make customizations as one wants to toolbars and be able to save them and back them up with no chance that a reset will destroy them. The V7 and earlier system could guarantee that in a couple of seconds with a couple of clicks. I haven’t yet found anything in V8 - no matter how much time and how many clicks - that can offer us that insurance.
Can you tell me more about “vulnerable if one has to do a reset”? It seems like you’re trying really hard to do something outside of the design of the current system.
Rhino wants to track the changes to your toolbars and window layouts by comparing them to the default configuration, you’re right.
But I’d like to focus on your initial complaint rather than the difficulty of the workaround, as it seems to me like the workaround shouldn’t be necessary.
hi @brian, I was planning to do exactly what Mitch is describing here, but maybe that’s because we are old-time users and trained to plan and work this way. And this is no longer needed?
Are you implying that if we do not do this workaround, and later we do a reset all our customizations will be saved and restorable?
Yes, I’d actually say it has been designed out of the current system in fact…
Before:
Everything that was toolbar content (not talking about placement) could be stored in a single file that one knew exactly where it was located, could back up in as many places as one wanted, transfer to other computers, etc. You could close the default and just have your custom .rui open, with as many tools that you wanted, whether they were copies of default tools or customized ones. It was even automatically backed up via .rui_bak - which, for example, saved someone just yesterday whose original file got corrupted somehow. It was completely independent of default.
After:
Some of the toolbar stuff is stored as part of Rhino, some of it as “changes to the original” in what looks like three different .xml files under the scheme name. I am assuming you could back up that folder and perhaps transfer it to another computer but it is something that is far more opaque than that simple little .rui file that you could just copy.
If you start messing with toolbars, copying buttons, changing macros, changing icon images adding new buttons and toolbars, deleting others, etc., you now have no idea really what it’s doing, where those changes are stored and their scope is. Previously it was all stored in that little .rui file.
I agree with … well… pretty much everyone. On everything.
Rhino toolbars were not perfect before, but now pretty much everything is worse!
On one side it seems somewhere someone tried to make things better, but the outcome is the opposite.
Everything seems more abstract and “ephemeral” , inaccessible.
This is one of the reasons because is difficult to try/test Rhino Wip/Beta in everyday work.
Why opening the “Show toolbars…” takes many seconds to open? (Not only the first time. Every time!)
My pc specs are good enough to expect a 1ms delay for this kind of “tasks”!! (like in rhino 7?) … and yet, this “complex operation” takes the same time on 2011 hardware! Is the list on the cloud?
Here juggling with the cursor while waiting. Rhino UI completely frozen until it opens…
What is that Libraries “default” …?
Why it glitch open at a different size and then it quickly rearrange to a shorter scrollable list?
This last point^ is very frequent on almost everything of the new UI: windows do pop at some random size and style and then it get fixed to the chosen final design.
This resize twice after simply moving it (slowed down the second time):
(and container still don’t remember sizes…)
All this “hiccups” on the UI make Rhino feels less modern than Rhino 7.
Actually less modern than Rhino 4. imo.
Please don’t ““fix”” things this way.
This is duct tape to fix a bridge.
Build a better bridge and use no duct tape at all. Please
(making the resize still happening but hidden, is using duct tape again, in case someone wondered)
No, I’m trying to understand the problem you’re trying to solve by creating a wholly new toolbar layout. I still don’t understand.
So fundamentally the problem is that you don’t understand where everything is stored, and there’s no mechanism for saving, backing up, and restoring the settings?
I can’t say that I understand it, either - so I’m not going to be able to help you. Pascal and John Morse designed this system; I’ll have to defer to them. I guess we should have talked about this in Barcelona… I had no idea you were going to drop this when you got back. And this forum is infinitely more difficult to communicate than face to face. Did you discuss with Pascal while you were near him?
You’re not actually simply moving in this case. You’re dragging the tab out of the container, dropping it on empty space. The old container is destroyed and a new one is created. It’s easier to see what’s happening if you do the same maneuver on a container with multiple toolbar tabs. If you want it to just move, drag the “…” gripper (the darker gray part to the right of the tab).
I know, I purposely did so.
It shows the engine underneath is trash (I’m sorry), or that it was really baldy used.
I can do the same operation in 7 and it’s smooth and quick.
Continuously resizing analysis tool windows (and similar) still makes one thread go high and you can see Rhino as “high consumption” in the task manager (also reported here).
The new UI really messed up everything. Was this worth? Messing up all Rhino users for the sake of few Mac ones?
But all this stuff can be seen in the instant you use Rhino Beta.
I’m not understanding why the youtrack issues are opened only if we report them one by one… can’t devs see those themselves? What is going on?
And this is a feedback from users that try sometime the beta.
Would those issues be addressed anyway or the whole system here rely on user report the problems?
If the latter, please hear the feedback as @Helvetosaur’s … we are all using Rhino since a lot of time here.
I personally feel completely lost at how manage toolbars now. Maybe I’m the stupid one. Lucky we have the Reset command now!
I was trying to re-create the “single file backup/exchange” system we had in V7. But that appears to be impossible…
That is the essential problem, yes.
I did say I would have some more time to test this week because I’m sitting in the back of a classroom observing without much else that I have to do. I did discuss this with Pascal somewhat, but as you know, there wasn’t all that much time to try and test stuff. I did propose to try what I outlined above, but Pascal was not sure if it would work either. His suggestion for making modifications - which I haven’t tried yet, but will - was to start from the other end - go into the macro editor and start making new custom macros, then assign them to buttons and put the buttons in toolbars.
In any case I am abandoning the idea of trying to shut off the default and substitute my own - it clearly can’t work that way. So again, back to square one, have to choose a different direction.
Aside from the backup issue, I am trying to see how I can get some of my V7 toolbar stuff into V8. Currently I have a copy of my whole V7 .rui running. However, it has fuzzy bitmap icons, and reading between the lines, using a V7 .rui is now considered “legacy” - if it works, fine, if it doesn’t, well, too bad. That is why I want to do a complete rebuild from scratch based on the new V8 system. I’ll get there someday.
The last concern is the same as others have expressed - my feeling is the complexity of the system will limit the number of people that will attempt customization. But maybe I’m wrong about that, like @gustojunk said, we’re oldtimers who are used to the old system, old habits are hard to break.
Having (almost) the same interface on both platforms is a good goal.
The few Apple users are not a few, and even if they are, they are just as important as the Windows users.
We are still in the early stages of the interface.
I’m confident that it will work out well in the end.
The toll to have a common interface, for now, is really bad.
Early? Here it says no more changes to the UI.
I don’t know where you can generate that confidence… I’d like to be able to do the same.
I’m scared.
I’m scared my future workflow will be as today: open 8 to use some new feature and then back to 7.
Icons in Rhino 8 are vector (SVG) files. The icons in V7 are bitmaps. They aren’t as crisp, and no, we haven’t put as much effort into displaying them in V8.
You’re probably right, and we do want to fix it. It won’t be fixed before we ship, though.
Mac users are about 1/3 of our user base.
It is early, for this system. Sadly, it got a lot more complicated than we wanted toward the end. I chose to focus the last 6 months of development of this system on merely being able to start and use Rhino. As you’ve pointed out, even that isn’t smooth yet. But that was the priority 1. We’re not giving up, and we’re not done.
We will continue to make changes in this system, including in the UI for saving and restoring configurations, until it works. We’d love to delight you, even, though that’s going to take even longer.
Common user interface was only one of the reasons for this technology change. We needed to switch away from MFC to be able to support dark mode as well as make it so we can update and modify user interface as a dramatically faster pace than we did in the past. It isn’t as much an issue with the underlying technology as it is with the fact that there has been a massive amount of change and this change requires optimizations with respect to issues that we will discover. I don’t think it will take long to make these tweaks once we find them.
