alt clicking on the toolbar icons on the mac. for example on the wifi symbol to get advanced wifi info, etc.
when doing cmd-tab to cycle through programs, if you let go, but the program is minimized nothing happens. But if you press alt just before letting go cmd, it will actually un-minimize the window. Its a bit tricky at first, but once you get used to it its very intuitive.
yes i know those (“Programmumschalter” / “app switcher” , but it is not a hidden rhino feature it is on the Mac os level … there is many more stuff in system preference and so on…
(for example alt + klick on Display ’ s scaled resolution showing more options… but somehow of topic)
kind regards from Zürich / Altstetten / Basislager -Tom
Thanks for writing this up. Coincidently, we were just discussing this perennial issue at a recent developer meeting here at McNeel.
Rather than rehash all the variousDiscoursetopics that have been devoted to the history of decision making around this issue, I’ll just say a few things, then attempt to track down or author TODO items for specific issues…but first the broad stuff:
Our hope is that both Rhino for Window’s and Rhino for Mac’s interfaces will evolve in to become more “Rhino-like”, rather than favor one platform’s UI paradigms over another’s.
Today, regardless of what you think of either interface, there’s general agreement that where the pain is most acute is for teachers.
For Rhino 8 (currently in RhinoWIP), we’re planning on making some meaningful strides to bring the two interfaces closer together. We’re in the early-days of planning right now, but we’re hoping to deliver dock-able toolbars to Rhino for Mac, based on a standard, cross-platform file format (likely .rui)
I’ll delve into each of your specific issues in a subsequent set of topics, but I just wanted to get that out of the way first.
Logged this here: RH-65746 Window > Floating Panels > list should be alphabetical
Yes, though minor, I think this is a great example of a papercut …I’ve created a tag for this: Win-Mac UI Papercut. Sure, alone, it’s not a massive pain, but they really add up. I’d like to make sure we don’t lose sight of these.
I’m not sure we’ve captured this in a concrete bug-tracker issue yet:
the separation into one shot / persistent on the Mac is not very fluent.
but I know what you mean by “not very fluent.”
Each time I’ve talked this over internally, there’s a lot of friction because I think we - well, Marlin - attempted to make Rhino for Mac’s OSnap UI behavior “more clear” (a very difficult task) and backing that out now might cause some problems. It’s not to say it’s not do-able, it’s just that “make it just like Windows” is tricky as the Rhino for Windows behavior is idiosyncratic too.
I’m trying to reproduce this one here and I’m having trouble. I thought I saw what you meant, but then I couldn’t do it again. Would it be possible to record a clip of what you mean by this one and show us? (Command+Shift+5)
This is one area that I think @JohnM is going to be working in the RhinoWIP…he can correct me if I’m wrong. I believe this requires a completely new cross-platform Button and Command Editor/Workspace Editor (if those two things can be unified).
recorded with quicktime at 0:13 / 0:14 you see me click the centersnap icon but no reaction in the command line.
drawing the 3rd rectangle …
but with the screenrecorder including mouse-clicks, the problem occurs much less. - but maybe also because a second program hooks into the mouse click / mouse up event ?
with another screenrecorder (screenflick) i could not reproduce this “micro-sleepiness.”
maybe it gets worse with a second monitor / video projector - the setting i have while working in the office and teaching.
Dear @dan
thanks a lot for having such a close look at my post.
great.
really appreciate.
point snap
I made my first Cad experience with Form-Z, Strata 3d, and other dinosaur.s. For me 15 years ago with Rhino V4 the trustable and predictable point snap was fantastic experience.
Actually i think a 3d cad software on a 2d monitor operated by 2d-mouse with 3 buttons will always have some amount of idiosyncrasy. But it would be a nice workshop to brainstorm 2021 state of the art point snapping UI, where the power of multi cores only calculated this aspect… i would love to have 2 cameras record my hand, and interpret 3d - gestures…(ok maybe in 2031…) - maybe it is a new thread ? “pointsnap 2022”
still waiting for voice recognition … _line from origin to _centersnap (speaking, not typing)
… still thinking about pointsnap 2022… if i have some ideas, i ll let you know…
… i’ve got a friend that is a mac OS user, and like everything about it.
He also uses rhino, and hates its UI.
He says it is so problematic to the workflow that he ended up using Bootcamp and just using rhino for windows.
I tried rhino for mac. Once. Never again!
Everything feels just wrong. Not different, wrong.
imho you should make rhino for mac UI exactly like windows version.
@dan
does it make sense to collect all this stuff in separate posts ?
any other approach to do this fine-tuning things, micro / minor / paper-cut bug reporting (that do not crash rhino, nor make results impossible - but make workflows unfluent) ?
In the very least it means getting rid of two codebases to maintain. No doubt there will still be some platform specific styling, but the future most likely shows more and more similarities.
