Ok guys.. i am getting really upset

@brian I agree with your ticket items.

But there is one important thing to add:
There must be an overall, default, best-practice, “rhinonic” UI-Feeling.
And this should be the default setting, before UI-customisation.

And this interface design / touch and feel should be the same for both platforms.

And I think this “rhinonicity” is really important (and could be sharper / more precisely designed).
CAD Programms are an interface to a complex technology - and this interface matters a lot. Have a look at all those different Programs based on the same parasolid kernel. CAD Programms cover this huge bridge between what picture is in peoples / users mind, and how … at the end … nurbs surfaces and there CVs are positioned. The way the UI and the commands are structured matter a lot. (this might explain the emotional background of this topic)

Rhino offers some commands that are really applied, abstract and far away from the core (“_filletEdge”) or much closer ("_removeMultiKnot, _applyCrv, _weight, _makeUniform, _makeNonPeriodic, …).
I think many discussions show a struggle regarding this amount of abstraction. Some users want full control over some tech details like CV layout, Degree etc… other users just want a “build a I don’t care surface with this curves”-command. It would be nice if this amount of easy access vs. tech details would be treaded in a nice overall concept / approach. Allowing newbies an easy access and pros a deep control.

I think it was a strategic mistake to not combine the new Mac-UI with some huge technology-step. (like SubD, or a bunch of new Surfacing tools). For example SubD forced me to accept and learn the gumball. The experience for existing users is a bit of “new interface - old functionality” - it would have been more rewarding “new interface - new powerful features”.

I totally agree that this forum is a great place and it is unique to have this great, direct contact to mcneel. But sometimes I doubt, if the loudness of some topics really represent the overall opinion of the users. I encourage mcneel (and I hope @brian manages to read my - sorry - long post up to here) to discuss other feedback settings / test scenarios to further develop the software. My suggestions:

  • key customers / power users / clients
  • Beta to Release hackathon - bring together everyday users and developers for one week.
  • classroom visits. bring together developers or people who develop overall strategy with first time rhino users (or when students first use the new tools) - I really think this it is very valuable to see those moments. (and if the developing job is done nicely, very rewarding) - “my classroom is open for you guys”. (to link to the ugly title of this topic)

sorry that this post got that long.
kind regards


I was about to start a dedicated topic about the downgraded execution of opening cascading toolbars. Your post was a good reminder for that, so I uploaded a video describing the problem and will create a new topic for it, because I consider it the biggest downgrade in Rhino 8 so far.


There were a number of huge technology changes made in Rhino 8 and many of the user interface issues are bugs that crept in due to these changes. Changes were made on both Windows and Mac so we could use modern user interface toolkits on both operating systems and doing so using a single common codebase. When rewriting code on both platforms for user interface we were bound to miss subtle niceties. We are typing as fast and hard as possible to get these bits back in place.

Several bugs being reported were not intentional decisions to make things work a certain way. The cascading toolbars bug the Mitch and Bobi just mentioned is a perfect example of this where we just need to fix the bug.


Dear @stevebaer - thanks for your answer.
sorry if my post was not clear regarding “technology steps” - of course there is a big step under the hood, on the UI library / Eto as you mentioned - but I meant more stuff that everyday user workflows will profit from. Push-Pull is a great and implemented example (maybe mostly for architects ?). SubD was a great promoter for Rhino 7. … wishes and features wished / missed in Rhino 8 is discussed in other topics… kind regards -tom

What kind of testing of actual, “real-world” approximating, day-to-day using of Rhino 8 did McNeel do before releasing this new UI? The kinds of bugs, use hurdles and extra precision clicking @Rhino_Bulgaria, @Helvetosaur and others are posting should have been caught in development months ago. I find them so glaring and obvious I’m hesitating to buy R8 before they’re worked out - and right now I have little faith that they will.

Stated another way, is McNeel relying on this forum for all its feedback?

PS - if you read this as a complaint, it is. But more importantly, I also intend it as an admonishment with an expression of hope.


Getting on a soapbox:

I think McNeel’s company setup bit them on this release. Beyond the examples you mention, check out some of the broken-printing and broken-pdf threads. Some really basic cases have been failing.

Check out the company directory at
Rhino - Contact Us (rhino3d.com)

I count 35 devs, 13 training/support, and 7 corporate. They have other offices too, but from what I can see this seems to be representative of the company setup.

That’s a lot of devs and absolutely no one with a primary job title of QA.

I realize that they have great support/training people with good domain expertise, but when you’re classed as support and you have a backlog of customers with immediate problems then it’s extremely hard to prioritize, both as an individual and as a team, longer term issues: “I’ve got 10 reported bugs to test today. Do I try to replicate and respond to them or do I spend today setting up test cases for the new feature dev X will have done at the end of the month and for the major release in about 6 months?”

To clarify what I mean by that: a QA is generally a domain (not development) expert who spends most of their time creating and executing test cases and the procedures to make sure things are done correctly. They also usually contribute to new features by explaining to the devs how the real world user processes work and how the UI can be designed to facilitate that. Then, they create a set of test cases for the feature before the dev starts implementation to avoid situations like “Oh, I didn’t know someone might want to do that. It would have been easy if I knew before I started coding, but now I’d have to throw away most of my work to support that use case.”

Devs can somewhat assist in QA because they know how their coworker might have implemented something and how an oversight might result in bugs. That’s a limited view of the problem though: to give an org effective QA, you really need people who have spent and continue to spend most of their professional time in front of real world user problems and processes, not a compiler IDE.

Technical note: Some of the regressions also make me wonder whether they should focus some significant effort on developing additional automated test cases to prevent regressions.

Ok, down off the soap box.

1 Like

You’re trusting the internet too much. Almost no one here has a job title and many of the names listed under development don’t ever write code while many of the names under support do write code.

Users have always been the primary quality control for Rhino.
Rhino8 was released with practically no user input.
Or to put it more accurately the user input for Rhino8 development was mostly of the form that the Rhino WIP was not functional enough to even test.

The main stumbling block was the User Interface. Ten months ago McNeel actually thought the UI changes were complete and close to being ready to ship:

1 Like

Apparently, that’s been working for gradual changes. I’ve only been actively following development since 7.

It works less well, in theory and recent practice, for a situation like changing out much of the UI tools framerwork in one release step and rewriting the PDF engine at the same time (among other changes).

Job titles aside, I’ll summarize by saying:

“There are several categories of bugs in the initial 8.0 release and even the current release which it’s hard to imagine having made it through an effective QA process which includes adequate resources directed towards proactive test design, regular scripted manual checks and exploratory testing, and automated regression checks. Explicitly without criticizing any individuals because my experience both first hand and from watching other interactions has been almost completely positive on that level, to me it seems that some of these negative outcomes are the result of company level priorities, planning, and management.”

I agree with your comments about their devs and other people really stepping up to try to solve problems.

re: the part I just quoted, that’s why I led with

(now bolded for emphasis)

1 Like

A good part of the QA is done by experienced users who work with the WIP’s/Beta’s and make suggestions/report issues here. They test far more “real-world” scenarios and ways of working than a dedicated QA person ever could. Most of the time that has worked pretty well, IMO it’s a great system. In the case of V8, I think McNeel got caught out by the size and complexity of some of the UI stuff and perhaps some incorrect assumptions as to how the system should work. There’s a lot more to it than that, but you would have to go back and re-read all the posts here going back a year or more.

Credit to the McNeel people, especially Brian and Steve, for staying on the front lines and taking the flak, and putting in the long hours to address the issues as fast as possible - thanks!


That’s not accurate for almost all of the features in V8 besides the UI. We have a tendency to concentrate on that because - of course - it’s the way we interact with Rhino. But there was a lot of other stuff that had quite a lot of input from the WIP testers.

I agree and that caused the cascading problem of a number of advanced users opting out of testing completely. I am as guilty of that as anybody.

At the beginning it was assumed that people would just get used to the new UI system. A fair amount of time was used at first in trying to explain to people posting with issues how all the new elements in the new system were supposed to work - at the expense of perhaps saying “Hmm, did we go too far here? What did we get wrong?”

Add to that the pushing of the Mac Rhino interface in the direction of the Windows Rhino interface, and some of the Mac functionality that was (inadvertently or not) removed from the UI and you have a perfect storm.

Lastly, IMO this release has the most “breaking changes” in the history of Rhino - maybe with the exception of V2>V3 - and perhaps the three year cycle was simply not enough to bring them all to the state of completion that we’re used to with Rhino releases.



Plus, we added support for Metal and built Rhino for M1. I know there are haters here about how it is right now, but despite that Rhino 8 for Mac is TONS faster in both display and rendering than Rhino 7 for Mac.

Most of them were reported and logged. And most of them weren’t fixed before we released. We probably released sooner than we should have. We didn’t quite realize that all of the bugs together made for such a glaring oversight. Like I’ve said before, we’re going to do a big study of what we could have done better so we don’t make this mistake again - but we’re working our tails off right now just to dig out from under the problems we caused.


3 posts were merged into an existing topic: Bug: Can’t work with Layers properly from the Status bar

From what I can see, the majority of Rhino beta testers (QA) are the regular forum members who actively send bug reports to “McNeel”, because their program (or the evaluation version) does not work in the way it’s expected to do. :smiley:

1 Like

2 posts were merged into an existing topic: Bug with the mouse pointer: Unwanted crosshair sight in Rhino 8

Meanwhile, pure command line users be like

Jokes aside, I think this right here is what makes Rhino great, people take the time to report and debate on stuff in the forums, being mostly polite and with the devs taking part in the conversation as well.

Yes, the Rhino 8 upgrade was a bit clunky because of the new UI and I did found some difficulties trying to get it closer to what I had in Rhino 7, despite basically using the right panel only as UI instead of commands, but things will get ironed out.


This thread has reminded me of what I thought many times for many years that McNeel is losing a lot of money by not being open source. Too small to be closed and too modest to not want to absorb pull requests. I know under the hood it’s a mess for legitimate reasons, but I think some part of the app or UI could be made open. I know that keeping a project open requires more work and you already have some projects open, but I thought the reason for not let you compile Rhino was to have certain quality standards and things under control, but this thread is an example of that not being delivered so I don’t really understand why it’s not open source yet. GH2 would have been ready to use years ago and many of those non-priority bugs would have lasted a service release or two.

1 Like

A post was merged into an existing topic: The OSnap panel is flashing When you press the Alt key RH 8