there is so many different UI elements and their layout has so many different alignments..
switch vs checkbox, vs highlighted / bold text fields (osnaps)
sliders vs numeric input
property-name to the left or right, value to the left, below or right
i think we need much more consistency here !
and much less variations.
same input type, same interface-element ! please,
i hope to see some polish here, please …
it will not get better if this cleanup is skipped to version 10, resulting in one more layer of evolutionary left overs …
and more people shouting
I’d add behavioral inconsistencies to the visual ones: some windows close with Esc, others don’t; some close on a double-click, others don’t; and Tab sometimes jumps to the next control, but other times inserts a literal tab even when that makes no sense.
there is another regarding interaction with the general rhino UI.
some command-panels allow to change Display Mode or Current layer - others don t.
see: Mac vs Windows UI inconsistencies
The toggles in Patch have been removed as part of UI Cleanup. Toggles are only used for global switches now
Sliders and spinners sometimes do the same but not always. Spinners have more fine grained control. Sliders often have a fixed (or temp. fixed) range
Side bar places labels on top or left, based on available space.
Dropdown is often used for when multiple choices are available and/or when space is restricted. Radio buttons for 2 options or when more space is available. If the options are not too lengthy, Segmented button is used as well, and I prefer it over radio buttons and dropdowns in that case, esp if you need to change options often. (GEC is a good example)
Note that this cleanup is not happening over night, and a lot of cleanup already went into Rhino 9. It’s a process.
Here is another inconsistency: the Text command does remember some settings and reverts to default for other settings.
Create a text and change Height, Model space scale, Font and alignment.
Then create a second text, and some of the changes are still there, while others are not.
Just chiming in but it’s also kind of annoying that some of these pop-up commands do start when I press Enter and some don’t. ShrinkWrap doesn’t - for example - and I’ve been working with meshes for the past 2 months and my mouse is getting worn out from all the clicking!!
Here’s another inconsistency: similar actions in the same panel place their dialogs differently.
In the Layers panel:
Clicking a layer’s color opens the Select Color dialog at its last-used position.
Clicking a layer’s linetype opens the Select Linetype dialog in the center of Rhino’s window.
At a minimum, I would like these dialogs, and other similar dialogs, to follow the same positioning rule.
Of those two behaviors, I slightly prefer centering them in Rhino’s window. Remembering the previous position can cause problems when switching between locations with different monitor setups: a dialog that was visible in the office may end up partially or completely off-screen at home.
However, my preferred behavior would depend on how the dialog is opened:
Opened with the mouse: place it near the click location, keeping the entire dialog on-screen. This would avoid repeated trips between the Layers panel and the center of the window.
Opened with the keyboard: center it in Rhino’s window. The two examples above may not have keyboard equivalents, but other similar dialogs do.
I think dialogs should consistently use Enter for OK and Esc for Cancel, with an Alt+<key> shortcut for every other button.
Here, OK and Cancel each have an additional keyboard shortcut, while Select, the button I actually need a shortcut for, has none.
Do you agree with this approach? If so, would you prefer me to report each inconsistent dialog as I find it, or will this be addressed across the dialogs as part of the UI cleanup without requiring individual reports?