Mac - Interface still behind Windows

Rhino Rhino for Mac
1

Dear McNeel, Dear @dan, dear @Verena
Using Rhino for more then 12 years, teaching at 3 schools as ART - still don 't understand - from a user perspective - why both interfaces are different. It s the first time that i do a bigger / complex project with several 100 parts,named cplanes, layers on the mac-side and struggle with the interface - even if there are many improvements in Rh6 / Rh7

Floating panels

DSC_5188
DSC_5188750Ă—1333 186 KB

there should be an easier way between Sidebar usage and Floating panels.
The Windows-Concept with tabs that can be dragged is much more intuitive.
On the Mac-side the double-Concept (Sidebar + Floating) does not convince me.

Please:

  • sort the Menu - see screenshot - by name. ( i would call it a small bug)
  • some fuctionality that allow “make floating” and “stuck to sidebar” for example a button in both the sidebar and the floating panel.
  • make sure that the position of sidebars is consistent: if i work with 3 or 4 Sidebars it should be possible to make Named-Cplanes floating - and if i stuck them back to the same Sidebar Section, if i call for example the command “_layers”, i want the panel always to be at position 3.

Mouse-Click-Waiting-Time
There is a really annoying detail: if i click an button in the OSnap Palette to handle one shot object snaps i have to wait for a certain time above the icon. if i click the icon (e.g. _quadrantSnap) and move the mouse directly after the click, the command / snap-option is not called.

Onshot Obect Snap, Project
Rhino has quite nice Object-Snap Features that work very well.
But only if handled correct.
combining gridsnap, smart track, many persistent snaps - the snapped points are nearly unpredictable - therefor i think temporary / one shot snaps are very important.
the shift-klick option on the PC side is great.
the separation into one shot / persistent on the Mac is not very fluent.
switching to one-shot view in the panel will not inform about persistent snaps and project

Doing some exercise with Orient, orient3Pt that needs to use scale1d and scale3d option together with project / not project in a class with mac and pc is a big pain to supervise. actually the best approach is to teach it twice.

Regarding this aspects the PC-interface is much smarter and offers more information on a smaller part of the screen.

Custom-Toolbars, Macros
doing a project with repetitive workflows it is really great to collect commands in a custom toolbar. on the pc you can do this by just dragging with hotkeys and intuitive right mouse menu.
Lets say you need a lot of lines with 200mm
the macro is simple "_line _pause 200 "
check out how long you need to to add a button in a custom toolbar on mac vs. Windows.
if you want a fast custom icon … the windows users can drink coffee meanwhile.
and again the workflow is completely different - twice the work to develop, document, teach, switch between operating systems…

Focus
it would be great, if entering some values, for example a name in the properties, that the focus returns to the command line.
If i enter a new name, “Z428” press enter i want to call the next command…
doing this as a misstake “offset” i name the object / curve.
pressing esc does not cancel the name editing (which should be confirmed by enter, or by focus leaving the panel)

Another Focus Problem: having the floating layer panel on another monitor - changing the visibility there - back to to main monitor i can directly pan the view.
but before i can select objects in the same viewport i need to click there to have the focus there.

thanks.

kind regards - tom

5 Likes
2

The Mac and Windows U/I are different by design.
It was decided long ago for Mac users would never use a Windows application, or a Windows application that just ran on the Mac, it would be a bad decision. This turned out to be largely true.

Since then, there seems to be some push back from people like yourself.
We are moving towards an interface compromise that is closer to each other.

That said, there are U/I peculiarities on Windows and Mac where there is no middle ground.

Moving forward, there will be some noticeable unification, but they will never be exactly the same.

3 Likes
3

I wonder whether that was really decided by somebody, or whether it was just two OSes developing in different directions, Windows post-dating the first version of mac OS by nearly 2 years.
Nowadays, most cross-platform applications have far more homogenous UIs than you seems to imply. The only exceptions that I know of are Microsoft Office and McNeel Rhinoceros.

After all, the only real difference UI-wise between Windows and macOS is that on macOS the Finder toolbar usually contains the program options and preferences, whereas on Windows those are glued on top of the application windows.

You could by the way choose to do your own thing, like Blender or other prominent programs do, instead of running OS convections behind.

5 Likes
4

Dear @John_Brock thanks for having a lock at my post.
I think it is more a push forward - i do not care about Apple Os vs Windows.
If a User Interface offers smoother workflows - let s do it.

And as I experienced the Rhino for Mac Development - the first step was not a visionary new GUI-Concept - it was just a proof of concept that Rhino-core can run on the other OS. And their was the wish for the “feels like a Apple”… But not sure if this was ever a deep GUI-Concept. - This is my perception, don t want to be negativ.

Actually i think that Rhino offers a great value for it s price, it has a very step learning curve, it has a very fair licence concept (no subscription), it is very accessible for students, that are not forced to by a 8000 Eur Licence after studying, it is widely spread in the universities also because of it s great API access, a great community - this forum, a direct contact to the developers (you) and there is grasshopper, and for many years there was no nice CAD for designers on the mac.
I really appreciate, that their is finally a Mac version that is competitive.

But if i do complex projects the Pc feels more fluent. And switching between systems - which is more and more common, is in some aspects not very nice. I know many designers that have a private Macbook and sit in front of a pc at work…

I bet there is not many Mac Users that bought Rhino because of the fantastic GUI -
Most of the points in my initial post are some GUI-Workflows / Elements that are solved in a better way on the PC.
My students claim, that the dialog style of the mac interface offers more overview. I agree on this for beginners.
But as i use the keyboard very intense - i like the more dominant command line on the PC.

And as universities / teaching / tutorials / accessibility of knowledge is very important - it would be very nice to have a unique interface. Then there would only be a rhino help file, not a rhino for mac help, and a rhino for pc help…

Picking the best of both - but bring it together. please.

kind regards

Tom

3 Likes
6

Development of Rhino for Mac started ten years or more after Rhino for Windows was initially released. My understanding is McNeel decided early in the development of Rhino for Mac that it would follow the user interface style and standards for software on Macs rather than follow the Rhino for Windows interface. I think John’s post above is an attempt to explain the rationale for that decision.

1 Like
8

deleting multiple nested layers with content.
Pc: one dialog “yes for all”
mac: multiple dialogs for each layer.
:rage:

9

On the Mac you can try pressing Alt and clicking an option. In many cases it will then do the same on all. For example if you have 20 windows in preview and you Alt-click to close one it closes all of them. I haven’t tried it in that specific case, but it might work.

The alt key is like the hidden hero of the Mac. So many cool hidden things Alt can do there.

10

"alt" as option / hotkey works for the Menus “Rhino 7”, “File” and “Window”.
for example you get “Save as” while pressing “alt” on the File Menu.

in many mac programs dragging with alt key means copy.
this is true for the gumball (mac &pc)
this is not true for none-gumball dragging.

any examples beyond that ?

11

My favorites are:

  • 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.

I use both of those all the time

12

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

13

Hi @Tom_P -

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 various Discourse topics 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.

-Dan

9 Likes
15

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.

1 Like
16

Would you say that your concerns about OSnaps are captured in these issues?

  • RH-36516 Right-click on OSnap checkbox behavior
  • RH-58777 Menu: Object Snap menu is different between Windows and Mac
  • RH-36815 Some App settings should be per document

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.

17

Yes, agreed, this one is a killer:

RH-64940 “Delete Layer” on Mac Not Offering “Yes to All” and “No to ALL”

@dale is on it.

18

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)

19

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).

2 Likes
20

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.

21

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…

meanwhile - thanks a log - kind regards - tom

22

… 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.

5 Likes
23

i do the same - bootcamp and even vm-ware (that works great with rhino 6 and acceptable with rhino 7)