Navigation Cube disappears during sketch edits! Why?

[simonb65]

Why does the navigation cube disappear when I'm in 2D sketch mode?

I still want the ability to swing the part around to see and measure things. I can move around the part with my mouse buttons or spacemouse, but not the cube ... because it disappears. It's not as if my view is locked to being perpendicular to the sketch plane, so why can't I still use the navigation cube .... Arrrrrrrggghhh!

To repeat a previous post. If you are allowed to do an UI operation, give the user the controls to do it. If your not supposed to do an operation, then take all of them away. The key to usability is CONSISTENCY.

 

[Max]

It was decided to not expose it in the sketching environment for a reasonably good reason. Due to a limitation of the current implementation by HOOPS, it is not possible to change tools and capture clicks while hovering over the view cube. What I mean by that is if you have the line tool selected, and you click on the view cube in sketch mode, you will both change the view and place a point behind the view cube. This is obviously not what you want.

Exposing the view cube in sketch mode would mean that it would only be usable when the select tool was active, which is not a practical expectation and would cause significantly more annoyance. Until we get an update, this is the nature of the view cube. So, we unexposed it when that issue is most severe, which is during sketching.

 

[simonb65]

What I mean by that is if you have the line tool selected, and you click on the view cube in sketch mode, you will both change the view and place a point behind the view cube. This is obviously not what you want.

But this is the exact same issue that happens when you're placing parts in an assembly view! You can't operate the cube without pasting a part instance into the workspace ... So why don't you hide the cube in that scenario? after all it's the exact same reason that you give for hiding in this instance.

I think the issue is that the view cube should take priority over whatever is the current operation or underneath it. That's the fundamental problem here. (as I've highlighted in a number of posts recently)

 

[Max]

That is true, and we probably should consider hiding it in that circumstance. But let's be honest - if we did that, this post would be about how it's hidden there too. It would be "an oversight", bad code, inconsistent. Nonetheless, part insertion probably does rise to the level of sufficiently "in the way" that we should disable it there. I've pinged dev about it.

Most things are not black and white. Some things are implemented with an approach that tries to minimize end-user confusion while maximizing development efficiency. We were expecting an update from HOOPS reasonably soon, which makes all this go away. One approach we could take is to audit every tool in the software to see on an individual basis if the view cube should be disabled, create a framework to make that happen, and then just delete it all after we got an update, which is a huge waste of time and would not appear any more consistent than it does today. The view cube would be disabled when you made a line, but enabled when you mirrored it, but disabled when you applied the mirror, but enabled when you made a 2D chamfer. It's not better really.

Or, just not implement the view cube at all - removing the issue and also 100% of the benefit of it. The other approach is fix the places the limitation is most readily an issue, tolerate the rest for a short time, and then get a fix that addresses everything.

It is the reality of working with component providers and dealing with limited resources. Tradeoffs happen. It's not ideal, but software development isn't an ideal thing. I'm not trying to say that issue isn't frustrating. But I do get the impression that some people on here assert or feel like people who design or code the software just "aren't even thinking about any of this stuff" and do things for no reason. That is not the case.

I think the issue is that the view cube should take priority over whatever is the current operation or underneath it. That's the fundamental problem here. (as I've highlighted in a number of posts recently)

Yes, of course. That is not possible without a fix from HOOPS. Ergo, the situation we are in.

 

[simonb65]

That is not possible without a fix from HOOPS

Time to lean on them a little harder perhaps! I know the frustrations of using 3rd party code and libraries, but with that desire to use them comes a stronger desire to give them reason to respond to issues. I know what that's like to have you hands tied by suppliers ... when it affects my products or customers, that's normally when they see a different side to me, and I don't take no or maybe for an answer. Maybe HOOPS needs a kick or two as some of these issues with the HOOPS engine are fundamental rendering, overlay and priority issues. They certainly need to speed up their fix releases.

HOOPS responsiveness to fixes and updates doesn't look good on the quality your product.

I would personally prefer to see a function working 99.9%+ and in the application than one added that's 50-60% and waiting on fundamental fixes. The cube is fantastic, it wasn't ready for inclusion in a major release yet though (for all the reasons I've mentioned in recent posts).