Region Overlap: Input is blocked #61554

New Issue

William Reynish · 2019-02-15T00:03:54+01:00

William Reynish commented

2019-02-15 00:03:54 +01:00

Middle mouse viewport interaction is blocked in the transparent areas of sidebar and toolbar with Region Overlap active.

We can solve this by letting the input fall through to the underlying area when not over a button or panel.

If needed, we could even make it more advanced, so that this is only true if the overlapping region has an alpha value of zero.

Middle mouse viewport interaction is blocked in the transparent areas of sidebar and toolbar with Region Overlap active. ![image.png](https://archive.blender.org/developer/F6613375/image.png) We can solve this by letting the input fall through to the underlying area when not over a button or panel. If needed, we could even make it more advanced, so that this is only true if the overlapping region has an alpha value of zero.

blender-admin commented

2019-02-15 00:03:54 +01:00

#62414 was marked as duplicate of this issue

William Reynish commented

2019-02-15 00:03:55 +01:00

Added subscribers: @WilliamReynish, @antoniov, @CharlieJolly, @schweppie, @Hexbob6, @freemind, @PierreSchiller, @SteffenD, @remotecrab131, @Thane5, @orvb, @brezdo, @iss, @0o00o0oo, @ideasman42, @RamiroCantu, @Regnas

Harley Acheson commented

2019-02-15 00:27:30 +01:00

Added subscriber: @Harley

Harley Acheson commented

2019-02-15 00:27:30 +01:00

Although I do agree that this can be dealt with in a number of ways, I think we should ALSO make the default starting theme show a small amount of opacity for those areas.

By having that panel faintly visible, rather than completely invisible, it would serve to show the newest users that the panel extends to the bottom. There would be no confusion about the behavior of the mouse pointer in that area. Even if they later change theme or that setting, they would have already been taught how it all works

We should consider other changes to the default starting theme too, for the same purpose. So have the Tools bar open to the point where it shows the too names, not just icons. That way they are initially shown and can be hidden, rather than initially hidden for users who don't know how to show them.

Although I do agree that this can be dealt with in a number of ways, I think we should ***ALSO*** make the default starting theme show a small amount of opacity for those areas. By having that panel faintly visible, rather than completely invisible, it would serve to show the newest users that the panel extends to the bottom. There would be no confusion about the behavior of the mouse pointer in that area. Even if they later change theme or that setting, they would have already been taught how it all works We should consider other changes to the default starting theme too, for the same purpose. So have the Tools bar open to the point where it shows the too names, not just icons. That way they are initially shown and can be hidden, rather than initially hidden for users who don't know how to show them.

george b commented

2019-02-15 10:09:28 +01:00

Added subscriber: @GeRo

george b commented

2019-02-15 10:09:28 +01:00

In #61554#620825, @Harley wrote:
Although I do agree that this can be dealt with in a number of ways, I think we should ALSO make the default starting theme show a small amount of opacity for those areas.

This is not just a cosmetic issue but also a consistency one because LMB & RMB w/ or w/o keys input work for viewport in that area but MMB and Wheel don't.

> In #61554#620825, @Harley wrote: > Although I do agree that this can be dealt with in a number of ways, I think we should ***ALSO*** make the default starting theme show a small amount of opacity for those areas. This is not just a cosmetic issue but also a consistency one because LMB & RMB w/ or w/o keys input work for viewport in that area but MMB and Wheel don't.

Harley Acheson commented

2019-02-15 17:22:01 +01:00

This is not just a cosmetic issue...

No, that is why I added the big "ALSO" to my comment.

In a nutshell, there is no confusion with these areas when "Region Overlap" is turned off. And when it is turn on, they also work in a manner that makes sense to users while there is some opacity. When they are at least partially visible it makes complete sense that your mouse turns into a "resize" cursor along the entire edge. And it also makes sense that ctrl-mmb-dragging causes the area to resize within that area's boundaries.

The confusion happens when the regions are invisible. It is certainly possible to change the behavior when opacity is zero. But that is not when the confusion starts - it starts when the panel is invisible. When that happens, as opacity is moved from 1 toward zero, depends on the color of the area and the background. So if you have a dark background but the area is white, then it will remain visible with an opacity of 0.02. But if there is less contrast in the colors it can become invisible at a much higher opacity.

We could also make it so that the behavior is changed no matter what the opacity, but that does introduce new oddness. For example, look at the following capture with the opacity set extremely low to help illustrate. If you are no longer able to resize the area from a position that is below the content of the area, then you could drag out as shown on the left, but then could not drag it back in, as shown on the right.

So I'm not saying there isn't anything to change or fix. I definitely think it should be thought through and improvements can be made.

But I am saying that ALSO we should give that area a very small amount of opacity on just the default starting theme. That way users would know that there is something there that can be altered or hidden. With it invisible by default users have no idea of its very existence. Having some opacity instantly shows new users that the tool buttons are not just floating over the 3D view, but are on a panel over the 3d view.

> This is not just a cosmetic issue... No, that is why I added the big "ALSO" to my comment. In a nutshell, there is no confusion with these areas when "Region Overlap" is turned off. And when it is turn **on**, they also work in a manner that makes sense to users *while there is some opacity*. When they are at least partially visible it makes complete sense that your mouse turns into a "resize" cursor along the entire edge. And it also makes sense that ctrl-mmb-dragging causes the area to resize within that area's boundaries. The confusion happens when the regions are invisible. It is certainly possible to change the behavior when opacity is zero. But that is not when the confusion starts - it starts when the panel is invisible. When that happens, as opacity is moved from 1 toward zero, depends on the color of the area and the background. So if you have a dark background but the area is white, then it will remain visible with an opacity of 0.02. But if there is less contrast in the colors it can become invisible at a much higher opacity. We could also make it so that the behavior is changed no matter what the opacity, but that does introduce new oddness. For example, look at the following capture with the opacity set extremely low to help illustrate. If you are no longer able to resize the area from a position that is below the content of the area, then you could drag out as shown on the left, but then could not drag it back in, as shown on the right. ![RegionOverlap5.png](https://archive.blender.org/developer/F6619426/RegionOverlap5.png) So I'm not saying there isn't anything to change or fix. I definitely think it should be thought through and improvements can be made. But I am saying that ALSO we should give that area a very small amount of opacity on just the default starting theme. That way users would know that there is something there that can be altered or hidden. With it invisible by default users have no idea of its very existence. Having some opacity instantly shows new users that the tool buttons are not just floating over the 3D view, but are on a panel over the 3d view.

William Reynish commented

2019-03-07 21:57:27 +01:00

@Harley You are right that making this semi-opaque will essentially solve it too. But I just think it would be a shame - especially on very large monitors in Object mode, a lot of screen space is then lost to the toolbar, which is why I am resisting this otherwise very simple and obvious solution.

If we could make it so you can only resize where the panel is, that would solve the issue without losing all the screen space to an opaque toolbar.

@Harley You are right that making this semi-opaque will essentially solve it too. But I just think it would be a shame - especially on very large monitors in Object mode, a lot of screen space is then lost to the toolbar, which is why I am resisting this otherwise very simple and obvious solution. If we could make it so you can only resize where the panel is, that would solve the issue without losing all the screen space to an opaque toolbar.

Harley Acheson commented

2019-03-07 22:34:59 +01:00

I definitely agree it would be a shame.

The only way I can really see solving it *properly"...

These side panels, and popovers too (!), could be made to not have any set initial vertical size, but instead size the container to the contents. And they would also have to be aware of a "maximum" that would be the extent of the containing area, over which the area would get no longer grow but instead gain scrollbars.

That would mean though that a side panel or popover that has everything closed would only really be a long as those close section names. But it would get longer as you open sections until it hit the bottom, then it would scroll.

It would still remain a bit of a problem that horizontally resizing occurs on an edge that is not visible, so I would still add small opacity to the background, but that would just be (in effect) a small margin around the area only, not all the way to the bottom as it is now.

Note though, that the above would solve the issue with these side panels, it would only solve some popover issues. Popovers behaving this way would work great only if they popped down. It is an unsolved problem how to elegantly deal with popovers that pop up that also have collapsing panels since moving the top of it up and down as sections open and close would be horrible.

I definitely agree it would be a shame. The only way I can really see solving it *properly"... These side panels, and popovers too (!), could be made to not have any set initial vertical size, but instead size the container to the contents. And they would also have to be aware of a "maximum" that would be the extent of the containing area, over which the area would get no longer grow but instead gain scrollbars. That would mean though that a side panel or popover that has everything closed would only really be a long as those close section names. But it would get longer as you open sections until it hit the bottom, then it would scroll. It would still remain a bit of a problem that horizontally resizing occurs on an edge that is not visible, so I would *still* add small opacity to the background, but that would just be (in effect) a small margin around the area only, not all the way to the bottom as it is now. Note though, that the above would solve the issue with these side panels, it would only solve some popover issues. Popovers behaving this way would work great only if they popped down. It is an unsolved problem how to elegantly deal with popovers that pop *up* that also have collapsing panels since moving the top of it up and down as sections open and close would be horrible.

Campbell Barton commented

2019-03-20 07:13:30 +01:00

Added subscribers: @IanFinn, @manda.3d.projects

Ian Finnimore commented

2019-04-08 13:44:27 +02:00

Suggestion for a possible solution to this: Nesting of 2 containers, with no mouse position testing on the outer container.

The outer container would do its docked left/right geometry as currently occurs, locking top / bottom to viewport and expanding left/right, but no mouse location testing. It would be resized only by the dragging of the inner container boundary. Effectively a totally invisible object with no direct interactions and always transparent.

The inner container would be docked top into the the outer container, and would adjust vertically to contents.
This inner container would be what responds for mouse over (cursor change) and hit testing for resize, eliminating the odd UX artifact of an invisible resize line and eliminating the UX problem of a visible portion of the screen not responding consistently to user input (some inputs work since the container doesn't respond and so pass down through to the viewport), all without resorting to throwing out the new transparency benefits.

Basically this makes the container system do most of the heavy lifting on managing this geometry condition without resorting to a undocked container that new code would have to manage. Only specialty code is handling the inner container resize events, driving them out the outer container while avoiding a event loop.

The background only applies to the inner container, and the outer is always invisible/transparent. This allows for contrast shading behind the tool icons only, which is ascetically better especially since the tool icons can double stack horizontally, so can be just a cluster in the corner.

I did not dig into the container code to see if there is some potential performance or data structure/library problem with this proposal, but if not seems like a simple enough change.

Suggestion for a possible solution to this: Nesting of 2 containers, with no mouse position testing on the outer container. The outer container would do its docked left/right geometry as currently occurs, locking top / bottom to viewport and expanding left/right, but no mouse location testing. It would be resized only by the dragging of the inner container boundary. Effectively a totally invisible object with no direct interactions and always transparent. The inner container would be docked top into the the outer container, and would adjust vertically to contents. This inner container would be what responds for mouse over (cursor change) and hit testing for resize, eliminating the odd UX artifact of an invisible resize line and eliminating the UX problem of a visible portion of the screen not responding consistently to user input (some inputs work since the container doesn't respond and so pass down through to the viewport), all without resorting to throwing out the new transparency benefits. Basically this makes the container system do most of the heavy lifting on managing this geometry condition without resorting to a undocked container that new code would have to manage. Only specialty code is handling the inner container resize events, driving them out the outer container while avoiding a event loop. The background only applies to the inner container, and the outer is always invisible/transparent. This allows for contrast shading behind the tool icons only, which is ascetically better especially since the tool icons can double stack horizontally, so can be just a cluster in the corner. I did not dig into the container code to see if there is some potential performance or data structure/library problem with this proposal, but if not seems like a simple enough change.

Campbell Barton commented

2019-04-23 22:21:08 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-04-23 22:21:08 +02:00

Campbell Barton self-assigned this 2019-04-23 22:21:08 +02:00

Campbell Barton commented

2019-04-23 22:21:08 +02:00

Fixed be3adb51de

Fixed be3adb51de

Mateusz commented

2020-05-18 15:34:36 +02:00