this really doesn’t matter at this time since there are maybe 5 mac users around here but just looking down the road…
the rhino for windows category is where much of my discussion takes place (and it’s not off topic discussion) even though i’ve never owned a windows based computer in my life.
i do think there’s a need for the mac rhino category as most of that stuff is completely off topic in regards to the RfW section.
dunno, just a thought with no suggested solution (and i’m not sure there even needs to be a solution… in all reality, it’s probably fine as is)
To me, that is the nice thing about discourse. It is so hard to categorize some posts since they could belong in different locations no matter what category names you come up with. At least with this system, you can see posts under all of the categories at once. Under other systems you would completely miss a post since it is under a category that you would never look at (or search results would recommend.)
True enough, but I’m sure it’s still on the wishlist for Discourse that the users can filter or turn off certain categories. When that gets implemented, we’re back to the way other systems work…
Nope. Definitely wanted here along with a separate “Mark all read” for each category. It’s fairly annoying when a dozen “News” category posts (for example) arrive overnight and I have to go through each one to get it to mark read…
IMHO, we are short one category. We need a “Rhino” category. Then we would have a place to discuss Rhino issues, a place for issues running Rhino on Windows and a place to discuss running Rhino on OSx.
Of course, this pre-supposes that Rhino will evolve so that it is truly OS independent and presents (essentially) the same interface to all users. Right now Rhino for OSx comes close, but there are some cases where where strict adherence to OSx standards in menu functionality is enforced by directing the Win-experienced user to the Mac-convention instead of just implementing the “Original Rhino” command directly with the Mac response and (perhaps) an informative add-on response that explains why it looks different and how it is normally accessed on a Mac.
Naturally, the same concept should be built into Rhino for Windows to support an easy transition for Mac-experienced users.
There really aren’t very many places where this is an issue, and could easily be addressed by a simple change of architectural policy applied to both (all, looking to the future?) versions.
I really wish this were true, but as far as I understand, the intention is exactly the opposite… That is to say to have two completely different user interfaces that operate using the same geometric/programming core. All indications that I have seen (from hanging out on the Mac forum mostly) seem to point in the direction of deliberate divergence, not convergence.
i’ve never written an app and my coding experience consists of a few small applescripts so take this for what it’s worth…
i just don’t think it’s practical at all for developers to make a mac app look identical to a windows version… (actually, it might be easier to do from a developing pov with some sort of multiplatform framework (wxWidgets?) [excuse my ignorance if those are the wrong terms ]… but those kinds of ports, that i’m aware of, are junk… even windows users will complain how much worse it is performance wise etc even though they look the same…
it’s nice that rhino for mac is using UI elements which are native to the OS… i just feel like you’re going to get a better user experience when you don’t stray too far from what the OS itself is offering…
an example of an app that went the other way is Vectorworks… i believe they made the right choice when making the windows version look like a windows app and using native UI elements/conventions instead of trying to make it look&act like mac on windows… that too sounds like a disaster waiting to happen…
it’s really a tough call i guess… im hyped marlin is going with the native UI when appropriate (as you’ve probably read me saying before mitch)…
i pretty much think the people who will suffer the most from two different UIs are people teaching the apps… not the students and not the users- they should be fine (unless they’re constantly switching between the two versions-- but people like that are already dealing with switch between two different OSes anyway so i definitely think they can manage doing it with an application)
i guess what i’m getting at is i don’t think marlin is so much ‘deliberately diverging’ or even ‘deliberately converging’… i think (hope) it’s more along the lines of doing what’s appropriate for the platform he’s developing on and using the available resources available through osx itself…
Please don’t misunderstand. I’m not suggesting that they look the same, just that they work the same. By that I mean the command syntax should be identical, the default toolbar contents and layouts should be identical and so should the default menu layouts and contents. For those control items that invoke OS-specific behavior (like options/preferences) Rhino should provide one Rhino command/menu item/toolbar button so it will work one way for any Rhino user and produce the analogous result in either operating system. A user who is using the alternate OS for the first time may be surprised by the different appearance but will recognize the information.
The main reason I feel this way is that I think most people will use one system primarily but may use the other occasionally. For this type of user having a “universal” interface would make the transition a non-issue. Many times the change will be necessitated by a presentation environment, which is the last place a user wants to look like a doofus as a result of a temporary memory lapse about which OS he’s using.
Because the Mac main menu system normally contains a place to edit and view preferences it makes sense to retain it as an alternative for the experienced Mac/inexperienced Rhino user, but it should invoke the “universal” Rhino approach and drive the user toward familiarity with Rhino and not the other way around. Rhino is the tool and the OS is just the environment. Rhino should merge the standards of both OS’s where required so it works the same on either one. The idea that Mac users must use a Mac interface and Windows users must use a Windows interface in their applications is quaint but outdated. Application developers may still be firmly rooted in their OS “religion”, but application users are mostly just interested in getting their job done. Having their tools available on two or more OS’s is just a (sometimes very valuable) convenience.
[quote=“AlW, post:10, topic:1637, full:true”]
Please don’t misunderstand. I’m not suggesting that they look the same, just that they work the same. By that I mean the command syntax should be identical, the default toolbar contents and layouts should be identical and so should the default menu layouts and contents. For those control items that invoke OS-specific behavior (like options/preferences) Rhino should provide one Rhino command/menu item/toolbar button so it will work one way for any Rhino user and produce the analogous result in either operating system. A user who is using the alternate OS for the first time may be surprised by the different appearance but will recognize the information.[/quote]
oh… right… i agree with that too… icons, menu layouts etc should be identical… i thought they were for the most part but i’ll occasional notice something like a double entry for a menu item and think some of that stuff is still being worked through/ cleaned up…
regarding the toolbar icons- something i see in windows that i like is how you can right-click on, say, Explode and get ExtractSurface… on mac, you have to option-left click for the same functionality but it took me a little while to figure that one out… this is out of my league as far as what’s actually possible in OSX with things like mouse events but i just assumed mac has to opt-click because the right-click won’t work.
but then there are some things on mac rhino which i personally like which i think marlin has implemented via his own vision… for example, i don’t have osnaps showing at all times… i get those via thumb buttons on mice or a gesture on my trackpad using ToggleOsnapPanelUnderCursor… it’s sweet in that the panel comes up right where&when you need it but it’s out of sight the rest of the time. i also get my layers panel and object properties in similar ways so i basically have my screen empty other than the viewports while drawing… to me, that’s pretty good.
i guess the full screen mode will need to be more of a framed thing with less floating panels which leads me to think you could also get that style when not in full screen?
anyway-- i should probably back up some because i might be speaking out of line as i’ve never used the official rhino before… i’ve only seen screenshots and videos of it… it’s possible i never will use the windows version so while it may sound like i’m arguing to keep the two platforms different-- i’m not so much doing so.
my main reason for saying stuff about this is that rhino on mac looks and acts very much like a mac application… it IS a mac app… so when i start hearing ‘change it so it’s more like the official version’ i just get a little nervous …i’m not suggesting no changes are in order (though i don’t personally have any problems other than some minor UI refinements/fixes)
…all i’m saying is if changes are to be made down the line, hopefully when i launch rhino, i’m left with the same feeling “ok, sweet… a mac app”
[quote=“AlW, post:10, topic:1637, full:true”]
The main reason I feel this way is that I think most people will use one system primarily but may use the other occasionally. For this type of user having a “universal” interface would make the transition a non-issue. Many times the change will be necessitated by a presentation environment, which is the last place a user wants to look like a doofus as a result of a temporary memory lapse about which OS he’s using.[/quote]
lol, yeah… i can see what you’re getting at… i mean sure, you’re going to have to remember it’s a command key instead of ctrl and if you press f12 on mac, you’re going to turn up the volume but for the most part, yes, a user should be able to switch between the two fairly fluidly and painlessly.
good sentiments- and i’m not against that either… what i like about your attitude up there is that you’re not saying either OSuser should be forced to conform to that of the other… instead, changes or improvements are viewed as benefits to all of rhino
[quote=“jeff_hammond, post:11, topic:1637”]
you’re not saying either OSuser should be forced to conform to that of the other… instead, changes or improvements are viewed as benefits to all of rhino
[/quote]
I came here to say this – I just created a support post for a geometry issue, and while I mainly use Rhino for Mac, I didn’t want to post it in that category because I was pretty sure it wasn’t a Mac-specific problem, and I didn’t want to restrict my question to a minority of readers.
I actually checked that the same problem appeared in Rhino for Windows, and then posted in that category. But it seems pointless to have to decide. If someone on Windows has the same question I did, then by definition it’s not a Mac-specific question; conversely, if it is Mac-specific, Windows users won’t be searching for it in the first place.
Also, I think the two applications are more closely related now than they were 6 years ago. The Mac version even supports 4View now! Perhaps, in a few years, I’ll even be able to use the spacebar to execute gumball transformations, instead of typing a number, hitting the spacebar, frowning, then hitting ‘enter’.
LOOOOL, you’re a savage, Jeff! At work I use a Windows machine, and really most people don’t realise how inferior it really is, because they haven’t ever tried anything else. I’m not saying that macOS is for everyone, but a well dialled-in Linux distro is also a thing of beauty.
I agree! In general there are too many categories and let’s be honest many distressed people don’t even care where they post. Most scripting related content always lands in the Grasshopper category, there seems to a believe that Grasshopper is “programming”.
Also the Mac category is counter productive anyways, since there is always a festering resentment against Mac users, which leads to many people not evening visiting the category.
Most problems are also Rhino related (i.e. strategies, geometry, etc.) and don’t have anything to do with the OS.
I’m also not sure about a solution though.
Yes, also the UI is well done, and visually references Windows Rhino. It’s not like both are two totally different programs.
Funny how I always felt the opposite, there are a lot of Mac users who seem to have this rabid hate of Windows and all it represents. You will find a bunch of comments to this effect in this forum if you go looking.
You have any real statistics or basis for this statement?
Haha, sure there are “haters” on both sides, but the number of Windows users clearly overweights the Mac users here. I work with Windows and Mac, but must say that macOS is the superior system!
Well, I haven’t done a social study on this, but the statement is an extrapolation of my own experiences. In the past, when I posted a general problem I had in the Mac category nobody or only a few kind people answered.
Then when posting similar issues in the Windows category, incognito as a Mac user, the response time was usually very fast. I see that this might not only be related to resentment, though.
However, when you for instance look at the “Rhino on Linux” discussion, you can easily discern how some people interested in the same piece of software, can be very divided, tribal, even resentful when it comes to defending their habits, like using Rhino on Windows or Windows in general.
Simple solution: with much of the code base unified, and with WIPs for both being released in unison, in future, the mac/win tag could go away for questions applicable to both, or add a specific ‘Both’ tag (Mac+Win). Leave the distinct tags for when the author believes a question is platform specific.
Harder to enforce accurate classifications…sure, but hey, there are people around whom enjoy house cleaning.
]… but those kinds of ports, that i’m aware of, are junk… even windows users will complain how much worse it is performance wise etc even though they look the same…
…i’m not suggesting no changes are in order (though i don’t personally have any problems other than some minor UI refinements/fixes)