Change default orientation widget

Absolutely. Note that having a default does not prevent switching widgets for static images. If the toolbar ­– which allows you to turn the orientation widget on/off – instead cycled through available widgets/styles (none/arrow-axes/ball+stick-axes/cube), it would be easy to switch for a screenshot.

A view cube marked with “+X/-X/+Y/-Y/+Z/-Z” would be unambiguous (because the axis text implies the “up” direction for the plane) but I agree less helpful than a pair of axes.

However, a lot of customers have also indicated that when they are interacting with ParaView (and even more with custom applications that use ParaView because the target audience is often less computer-savvy), they prefer a view cube to axes. Personally, I prefer the ball+stick widget, but the default for ParaView should focus on what lowers the entry barrier for potential users. The default can easily be permanently changed by users.

I think the proper strategy for color choices is to use existing or add new entries to the color palettes ParaView provides. Since the default palette (Print, Dark, Light, etc.) is a user preference, this can be preserved. There are not already color blind palettes, so I filed an issue to add them.

I also want to be clear that there are several separable issues here:

  1. What is the default orientation widget?
  2. What are the shape and default interactions provided by the default orientation widget?
  3. What palette is used for the scene as a whole (which should also affect the orientation widget).

I’m not sure if this idea has been floated, but what about switching the widget when the mouse hovers over the space? So you would get the current widget (or some visual improvement) when the mouse is elsewhere and the widget changes to a box when you hover over it.

1 Like

That would certainly address @GregVernon’s issue with static images. You might also use semi-opaque cube faces with the ball+stick model inside the cube.

1 Like

We actually have this issue in our Coreform Flex application. Challenge: which way is X+?

Note how Autodesk Fusion handles this (top-right)

Both images are unambiguous, but the second is more helpful. The reason the first is unambiguous is that the orientation of the text (“Z+”) implies the orientation of the +X and +Y axes. If Z+ is not upright, you can deduct the transform to the X and Y axes. But this introduces cognitive load.