Yes, I think it should. The Alt-Z key feature in Pose Mode is actually different from X-Ray, specific for bone selection, when the bone is inside the mesh.
I get why they are different, but its a bit confusing, I just think it would be easier that if you are solid in object mode and go into posemode and you set posemode to xray, when you come out to solid mode is still solid so you need to go an extra step again to see it how you expect it
It’s confusing because we make it seem like two different features are the same feature. We could unify it so it’s the same thing, or separate it more and use two different shortcuts.
It’s really nice to see many of the pop up confirmation boxes finally gone. Makes the daily bread and butter things like saving scenes much more comfortable. There are a few of them left though, still occasionally creating frustration, such as new folder confirmation pop up, which is especially annoying when creating new folders with a shortcut:
“Oh noes! I accidentally created a new folder. All my work is lost!” … said no one ever
Middle mouse viewport interaction is blocked in the transparent areas of sidebar and toolbar with Region Overlap active. Screenshot shows a real life window arrangement where mouse input is taken by the invisible window. While this is not a technical bug ( intended behavior ) it is less than optimal design and an annoyance.
Solution
The active area of sidebar&toolbar can be made to re scale dynamically just around the visible content.
“Playback” menu for Animation should be called “Preferences” or “Settings” – Almost none of the top options have anything to do with “Playback” at all.
I can understand the logic of putting “Limit Playhead to Frame Range” checkbox in a generic (low-use) menu, but I would never have looked there for it. – Like others here, I didn’t even know this option still existed. D:
It can be solved - probably fairly easily. When mouse cursor is not over a panel or button, input falls through to the underlying viewport.
Someone just has to do it.
Core developers are in bug-fixing mode currently, so these kinds of issues aren’t being worked on. If anyone from the community is willing to work on it, that would be great.
If not, hopefully it will be tackled before release.
IMHO almost all the confusion with those side panels comes with the combination of region overlap when also using an opacity of zero for region background. If you set the opacity to something that makes it even barely visible then the behaviour makes sense. I’m not certain we can, or want, to make it work differently if opacity goes under a visible threshold.
There is a big advantage in having the opacity be zero there. A lot of screen space is regained. And even if opacity is non-zero, input could still go to viewport underneath.
On the bottom of the left side it makes sense that users are confused. The panel resizing will seem to extend past the panel size and ctrl-drag resizing seems to affect the wrong region.
But set like the right that confusion is gone. There is no idea of resizing below the region because it is that long. And it is that long because all the sub-panels can be expanded. Region resizing also makes sense to do in that area.
So I’m not certain how fix the behavior so it makes sense as you change opacity…
Everything seems simple to implement except what users ask for. We are still waiting for it to become optional to have the tool settings menu in the sidebar and put it on the left of the activetools.
And again, I am not saying we should get rid of zero-opacity on these regions. I’m am just saying it is hard to think of a changed behavior that works along the spectrum as you change opacity.
As an example, here is another screen capture. Still with “region overlap” on, but with a much higher opacity:
How do we treat the region below the collapsed panels? Do we not allow the region to be resized for its bottom 3/4? How do we explain to users why they cannot? Do we also not allow region resizing there? Why?
