[BUG] Glitchy Rhino 7 preference pane?

[diff-arch]

Hi,

I think - with peace and love - that the Rhino 7 (7.7.21131.13002, 2021-05-11) for macOS preference pane deserves a little more love UI-wise!

What’s for instance up with all that free space towards the bottom?

It’s not very aesthetically pleasing, and the window can’t be resized by dragging its filleted corners.

Switching between different preferences is kinda glitchy, too! Check this out:

Why can’t we mac users get something like the Windows preferences? Or at least something a little more easy on the eyes?

No mac app that I know really has this style of preferences. Also the performance is kinda terrible!

I frankly don’t get it.

[Philip]

@diff-arch

Why can’t we mac users get something like the Windows preferences?

Yeah…

Philip

[diff-arch]

bump

[dan]

That dead-space at the bottom of the Preferences dialog is a bug. I logged it here:

RH-64294 Autolayout: Preferences: too much dead space

[rudolf.neumerkel (Rudi)]

regarding resizing and UI: for me it seems to be coherent with how the preference pane works in general in macOS, no?

[diff-arch]

Thanks, @dan! What about the glitchy transitions or ghosting between different preference subcategories like shown in the video?

[diff-arch]

@rudolf.neumerkel

for me it seems to be coherent with how the preference pane works in general in macOS, no?

Your showing the macOS System Preferences pane! Its equivalent on Windows would be the Control Panel. Do the Rhino Settings on Windows look like the Control Panel?

I’m talking about app-specific preference styles, where usually every body does what they want - hopefully in good taste -, but if you’re looking for a macOS “default” style, here are some references:

Some alternative settings styles that I find mostly successful for the number of settings the applications have under the hood:

[dan]

@diff-arch

What about the glitchy transitions or ghosting between different preference subcategories

That could very well be an artifact of the bug itself, so I’d like to tackle that first and see.

Perhaps TMI: macOS uses a constraint-based system to layout dialogs - called Autolayout - that “inflates” and “deflates” dialogs “on the fly.” It looks to me like we have a macOS version-dependent Autolayout regression bug here. If Autolayout is broken on these dialogs, it’s likely macOS doesn’t know how to best animate the transition. But one thing at a time.

Thanks again for reporting this.

[diff-arch]

I see. Thanks for clearing that up!