This post is about PureRef scenes with multiple levels of hierarchy.
For better reference, you can download a very small PureRef file with the issue present here:
https://drive.google.com/file/d/11fqtSKDJKxqoYrTl3gnjs2q-hX0Rpels/view?usp=sharing
A screenshot of the scene is available here:
https://drive.google.com/file/d/1DVUBDg4lfVdRjCZemOHtb9TNPH4mRLJh/view?usp=sharing
Alternatively, you can also create a very similar setup by just multi-level nesting different images/notes.
When the user clicks on an element, the current behavior is that the bottom-most level element underneath the cursor is focused.
So when multiple objects are grouped together, then the largest group will always be focused when
- Either of the elements contained within the group are clicked
- The group frame is clicked
This leads to the issue that when a scene contains several nested layers of objects, the user has to essentially spam left click to get to the element that they want to get to.
Even just a few layers of grouping for visual separation lead to far more clicks than should be necessary.
In the shared example file, you can see how many clicks it takes to focus the note "Layer 3". If you want to change the text, you'll have to go through that every single time.
I am proposing to change the behavior, so that the top-most visible element is focused instead.
In practice, this would lead to the following behavior:
- Any image/note that's directly clicked, will be focused, no matter how nested it is
- Any group frame that's directly clicked will focus the group.
In the example file, you would click on note "Layer 3", which would directly focus it.
This shouldn't lead to a problem of losing control, as you can achieve the previous result easily by clicking the group frame of the group you want to move.
Thank you for the suggestion! There's functionality to change this behavior on a per-group basis using the "Lock group" toggle button in the group toolbar. Have you tried this? The last selected lock state should be saved as you create new groups.
We know that there's different use cases where one or the other navigation method is preferred, so we opted to have it configurable.