I agree with mitch, maybe my previous post wasn’t articulated enough, but today I’m setting up a new laptop for me and transferring my UI settings seems very counterintuitive.
My steps below is to slightly tweak the UI to get my popup to work in addition to additional contained for design visualization.
1- Copy my popup toolbar .rui and reference it in the options
2- Copy my popup container .rhc and load it in my session.
3- copy the window layout .rhw and load it.
4- manually go to options and adjust icon size for the toolbar and tab sizes for the container.
5- Restart Rhino (since not all of the UI updates in Realtime)
6- load additional panels part of the Right container. (linetypes, Block Defs, Named Views, Cplanes…etc)
7- Stretch the standard toolbar to make more room for the icons to display properly due to step 4 above.
8- still get the selection filter panel persistent next to my osnaps (I swear I did remove it from that container)
9- Rearrange my popup container.
10- still get a weird grasshopper icon showing up.
Do we need all of these steps to restore a UI config? I don’t think so.
Thank you for setting the YT, I hope that a more streamlined process for backing up and transferring the UI will be implemented soon. I previously discussed the issue of fragmented UI controls. Perhaps my explanation in the following post wasn’t clear enough:
To summarize, constructing or rebuilding the desired UI in Rhino now requires visiting several sections of the software. Previously, syncing my UI was a two-step process involving RUI for toolbars and Rhino Options for everything else. I always kept the latest configuration on the cloud for easy access in case of a system reset, reinstallation, or machine replacement.
Now, the process feels more fragmented. Toolbar RUIs are managed separately from Toolbar Icon sizes. The container tabs are handled independently from the container objects or locations. Both Tab and icon sizes are located in the options but lack the ability to save to Rhino options.
Additionally, resizing the icons or tabs doesn’t automatically adjust the containers to match the object sizes.
Also
, the lingering topic of container setting menu icons alongside the grip handles is also being discussed a lot here.
While I appreciate the detailed and adaptable nature of setting up a UI framework theoretically, it’s also important to acknowledge its ability to reflect the varied applications of Rhino users. Although our feedback on the UI might seem belated, it’s worth noting that many of us, myself included, needed time to fully grasp the new UI’s structure. I’m curious to see whether new users will be taken aback by its unique complexity.
I don’t think the current system can and will change drastically.
I also think the system makes sense from a coder’s point of view.
For a user it’s at least not easy.
As far as I know, this new system stores the differences to the original set.
For example, if I copy the Circle button to another toolbar, the result is not independent, it references the original button.
If this assumption is correct, then a “Make independent” function would be good.
Idea:
A new function ‘Ex/Import UI settings (*.rhz file)’.
This rhz could be a zip file containing all required files.
In this function the user can choose what to export; toolbars, containers, all or whatever.
On import, Rhino automatically detects which file to copy to where, etc.
This way we only had one file to deal with.
Easy to back up and distribute.
I think that is a given - there will be more bugfixes and improvements, but given how much has been invested in this and how close we are to release, the basic structure is here to stay.
I think this already exists, I have to go back in and find where it is…
Agreed,
This RHZ export should be close to the reversal of the new _Reset Command, and should include.
1-All user created RUIs
2-All user created RHCs
3-All user created RHWs
4-Optional toggle (export plugin’s toolbars)
5- UI related option variables .ini or .xml (toolbar icons, tab sizes, appearance colors, popup settings)
6-I still have no idea how to handle stretching or shrinking the containers after adjusting the toolbar tabs or icon sizes , potential way is to automatically activate “fit to content” on reload?
This sounds simple, and is how previous versions of Rhino worked, and actually contributed to a number of problems with Rhino not “staying how I put it”. The problem is this: when you’re resizing the Rhino mainframe, all the containers need to resize. When they resize, their contents also need to resize.
But if we make it so that icons can instead say, “hey, container, fit yourself to me”, then we have a “who is in charge” problem of container sizing. And, my guess is that the moment we try to put the buttons in charge of sizing the containers, we end up with the same bugs we had before of “Rhino keeps rearranging things”.
I said this in the other thread, but I’ll repeat it here. This system is big, complex and complicated, new, and unfinished. We’re not proud of it yet, and we’re not done with it yet. And none of these complications are going to get resolved before Rhino 8 ships. We’ll chip away at it with service releases until it’s a lot less bad (and maybe even good).
Now that we have Window Layouts, do you expect those to be part of this “one file”? I believe I’ve been told that button arrangements are not to be considered part of the Window Layouts system - that they’re separate things. I guess some people think that you should be able to share Window Layouts without screwing up toolbar configurations. I’m not convinced. What do you think?
As far as I understand the criticism is not about the Window Layouts, at least I had no comment on them.
Window Layouts do work fine.
I expect a single file that holds all additional toolbars, including the container they live in.
There can be several single files that can only add but never remove something.
What I don’t like to see in the UI can be easily turned off in the Windows - Container menu.
And then saved as a new Window Layout.
To keep it simple, I would remove some UI dialogs completely:
_Containers - replaced by a ‘New Container’ dialog that asks for the so called ‘library’.
_Macros - we want to make a button, not a macro.
How it works behind the scenes doesn’t matter to the user.
Just throwing a thought out… the context is the merger of Windows and Mac interfaces and the already-published comment that significant revision to this is going to have a long lead time anyway.
If all of this were scriptable (each menu action and drag/drop has an equivalent script command), then:
the cost of iterating and experimenting wih UI, or recovering from a mistake, goes from an ordeal to a reset+rerun
One file or multiple files, user’s choice
Burden on McNeel lessened- if a workaround exists, it will be found and shared. A scriptable series of steps is much easier to work with than a bunch of files representing final state. That includes bug reports and replication because there’s no “how did we get to this state?”
do you think a single one-stop UI config command / dialogbox can help? where most of the UI settings are aggregated so the user can manage the configuration without jumping between options / dropdown menus and dialogboxes?
this may help not to have things reengineered and sounds a bit more doable as well.
At the risk of rambling a bit (this is speculative compared to my other comment):
I suspect that at the moment some configuration is dependent on the order in which commands are executed (state-dependent). In this context, ‘simply’ (dangerous word) exposing the set of actions/commands currently available for scripting would get you to where I suggested above.
A state-free model, which would probably be the case if a big flat tree/list/table of parameters, lists, and options was presented as you suggest, is generally viewed as superior in the UI world for a host of reasons.
How feasible it would be to do that given the way things work internally, including wherever they are in the Windows/Rhino UI harmonization, I don’t know. For example, whether a block of icons and the actions which configure them are viewed as assigning coordinates in a grid, or as sequential random access insertions to a list as might result from drag/drop into a toolbar, or in some other way.
I’ve been an avid Rhino user (modeling and programming) for a long time and what I’m reading here doesn’t reassure me at all about what’s to come.
I hope like a child at Christmas to see the latest version of Rhino correct the mess of the docking system of the user interface. And I’ve wished it for Rhino 6 and Rhino 7.
Unfortunately, it seems clear that this detail is not a priority. I’ve written about it many times on the forum. I tried WIP 8 a few months ago and nothing seemed to work any better.
I’ve also just installed 7 on a new computer, and it’s plunging me back into this interface configuration nightmare.
On a daily basis, Rhino is fascinating; it’s like driving a high-tech car with a cardboard dashboard held together with hot glue.
Maybe this comment doesn’t do any good in practice. I only hope it puts some weight on this persistent problem.
Make a window layout with the modified UI on the old computer
Export the window layout to disk
Import the layout to the new computer
Restore the layout?
Custom RUI files and RUI modifications are stored in the RHW file and will get applied when importing the file on the new computer.
Hello @JohnM
The custom rui has been successfully imported during .rhw import.
what is not being imported, so I had to import them manually.
1- Containers: I have these RUI files grouped as containers (such as my new comprehensive popup container)
2- Appearance Settings (Tab size, Icon sizes)
If these 2 groups of items can be hosted in the same RHW, this can be a great solution very comparable to the zip file approach mentioned by @Charles
Containers will get created when you restore the window layout after importing it, settings are not currently part of the RHW file, you can use OptionsExport and OptionsImport to migrate settings.
now if you ask me, I’d prefer having these 2 variables for icon/size image size to be included in the RHW as well for 2 reasons.
1- can make multiple window layouts based on screen configurations (1080p Laptop screen, 1440p, 4K, ultrawide…etc), so your icons can scale based on the desired layout configuration.
2- since rhw containers are positioned, and scaled from the Rhw, It makes sense for the Tabs to follow the containers size and vice versa, the container can resize itself when the icons / tabs are increased.
this is what I ended with, smaller icons with oversized containers:
Try to delete one of the icons in the toolbar (by dragging it out of the container while holding down Shift). I constantly get the two neighboring icon merging.I have documented this with a video send to Support…
Also try to shift from Icon Only to Text+Icons and reshape the container in a “tall shape”. Use Rightclick > Size to Content and return to Icon Only, I’m 95 pct sure that you will get at least one icon like your GH “ghost”
