UI: Fix scrollbar highlighting outside of regions #105973

Guillermo Venegas · 2023-03-21T21:35:32+01:00

Guillermo Venegas commented

2023-03-21 21:35:32 +01:00

Scroll bars have an extended action zone that helps highlight
when they can be used as a slider.

However, this extended action zone can overlap other regions,
which can cause the bars to appear active, while the cursor is in
other regions.

To address this issue the scroll bar's action zone is no longer
extended over other regions.

Scroll bars have an extended action zone that helps highlight when they can be used as a slider. However, this extended action zone can overlap other regions, which can cause the bars to appear active, while the cursor is in other regions. To address this issue the scroll bar's action zone is no longer extended over other regions.

👍 3

Guillermo Venegas commented

2023-03-21 21:41:41 +01:00

Here is an image showing the before/after.

Also here a video showing the before and after.
video

Here is an image showing the before/after. ![image](/attachments/d8365725-71ce-44ab-b510-8cb5bc70b05d) Also here a video showing the before and after. [video](/attachments/11ae5650-a785-45fa-934b-8a8ed25f101a)

image.png

42 KiB

2023-03-22 17-18-06.mp4

1.4 MiB

Guillermo Venegas force-pushed scrollbar-visibility-sidebar from c5f1244fde to b8b82d8fbe

2023-03-22 22:46:46 +01:00

Compare

Guillermo Venegas closed this pull request

2023-03-22 23:03:02 +01:00

Guillermo Venegas reopened this pull request

2023-03-22 23:10:33 +01:00

Guillermo Venegas force-pushed scrollbar-visibility-sidebar from b8b82d8fbe to 88c82facc6

2023-03-22 23:27:49 +01:00

Compare

Guillermo Venegas force-pushed scrollbar-visibility-sidebar from 88c82facc6 to d93b53703f

2023-03-22 23:29:07 +01:00

Compare

Guillermo Venegas changed title from ~~UI: Fix scrollbar showing on sidebar focus~~ to UI: Fix scrollbar highlighting outside of regions

2023-03-22 23:30:10 +01:00

Guillermo Venegas force-pushed scrollbar-visibility-sidebar from d93b53703f to 1c99a9d5cf

2023-03-22 23:46:17 +01:00

Compare

Pablo Vazquez added this to the User Interface project 2023-03-23 00:40:51 +01:00

Pablo Vazquez added the

Module

User Interface

label 2023-03-23 00:41:10 +01:00

Harley Acheson commented

2023-04-07 19:55:01 +02:00

I prefer this behavior too, but I don't think there will be consensus regarding it. I have proposed the same a very long time ago, but the idea was not accepted.

When the mouse approaches a scrollbar from a different area (normally when moving right to left), you are not liking that the scrollbar becomes wider and more active-looking before it even crosses into the area. But that is considered by some to be a feature and not a bug. Even the gradual nature of the changing scrollbar width, versus an instantaneous change from narrow to wide, is something that is wanted by some.

In the times when your intention is to interact with a scrollbar it does help the aiming for it with the current behavior. It does add extra movement if you are are intending to just transit over it. And it is weird when your are really intending to interact with something near the edge of a different area. But the instantaneous width change is more distracting in many of these cases.

Again, I agree with you as I am someone who prefers instantaneous feedback and doesn't mind abrupt changes. But am warning you that this might not be wanted.

I prefer this behavior too, but I don't think there will be consensus regarding it. I have proposed the same a very long time ago, but the idea was not accepted. When the mouse approaches a scrollbar from a different area (normally when moving right to left), you are not liking that the scrollbar becomes wider and more active-looking before it even crosses into the area. But that is considered by some to be a feature and not a bug. Even the gradual nature of the changing scrollbar width, versus an instantaneous change from narrow to wide, is something that is wanted by some. In the times when your intention is to interact with a scrollbar it does help the aiming for it with the current behavior. It does add extra movement if you are are intending to just transit over it. And it is weird when your are really intending to interact with something near the edge of a different area. But the instantaneous width change is more distracting in many of these cases. Again, I agree with you as I am someone who prefers instantaneous feedback and doesn't mind abrupt changes. But am warning you that this might not be wanted.

Guillermo Venegas commented

2023-04-12 20:15:26 +02:00

Ah, I did not know all that, thanks for the comment.

Now knowing that this is a behavior expected by users, the patch could be changed to add this proposed behavior depending on a user preference, with the previous behavior set as default.

Ah, I did not know all that, thanks for the comment. Now knowing that this is a behavior expected by users, the patch could be changed to add this proposed behavior depending on a user preference, with the previous behavior set as default.

Harley Acheson commented

2023-04-12 20:23:24 +02:00

Ah, I did not know all that, thanks for the comment.

No worries.

Now knowing that this is a behavior expected by users, the patch could be changed to add this proposed behavior depending on a user preference, with the previous behavior set as default.

Adding new preferences is also a steep climb, as it should be. We always try to do the "right thing" without the user needing to choose something.

Personally I would leave this PR as it is. It is in the review queue and will be looked at eventually. Just don't take it personally if not accepted.

> Ah, I did not know all that, thanks for the comment. No worries. > Now knowing that this is a behavior expected by users, the patch could be changed to add this proposed behavior depending on a user preference, with the previous behavior set as default. Adding new preferences is also a steep climb, as it should be. We always try to do the "right thing" without the user needing to choose something. Personally I would leave this PR as it is. It is in the review queue and will be looked at eventually. Just don't take it personally if not accepted.

Guillermo Venegas force-pushed scrollbar-visibility-sidebar from 1c99a9d5cf to 753baece9f

2023-05-30 20:21:05 +02:00

Compare

Harley Acheson commented

2023-08-15 21:29:48 +02:00

@guishe:

Earlier in this thread I mentioned that although I personally prefer the behavior proposed in this PR, the current behavior is by-design and was preferred by others. Mostly for the avoidance of sudden visual changes.

However, we just discussed this among the UI Module and well all agree that your proposed behavior is actually what we want. The current behavior can give the impression of influence at a time when the operation cannot proceed. As in you see the scrollbar getting bolder when you can't actually move the scrollbar. Having a more sudden transition when approaching from outside the region will also give better feedback of area crossing.

This is good news. Unfortunately, although we want the result that this PR gave, you will find that this particular solution no longer applies. This is because we no longer test against the rect of the scroller action zones, but instead use the region's scroller verts. This way they are properly positioned and sized when 2D scaled - #108295

So basically we do want this result but you have a think of a different way to do it. If you are unsure, I can investigate and point you toward a solution within a day or two.

@guishe: Earlier in this thread I mentioned that although I personally prefer the behavior proposed in this PR, the current behavior is by-design and was preferred by others. Mostly for the avoidance of sudden visual changes. However, we just discussed this among the UI Module and well all agree that your proposed behavior is actually what we want. The current behavior can give the impression of influence at a time when the operation cannot proceed. As in you see the scrollbar getting bolder when you can't actually move the scrollbar. Having a more sudden transition when approaching from outside the region will also give better feedback of area crossing. This is good news. Unfortunately, although we want the result that this PR gave, you will find that this particular solution no longer applies. This is because we no longer test against the rect of the scroller action zones, but instead use the region's scroller verts. This way they are properly positioned and sized when 2D scaled - #108295 So basically we do want this result but you have a think of a different way to do it. If you are unsure, I can investigate and point you toward a solution within a day or two.

Guillermo Venegas commented

2023-08-16 01:49:18 +02:00

Thanks for letting me know, I'll take a look at the changes that have happened to the code since then!

Guillermo Venegas force-pushed scrollbar-visibility-sidebar from 753baece9f to 5741a5d433

2023-08-16 02:19:41 +02:00

Compare

Guillermo Venegas added 1 commit 2023-08-16 02:20:06 +02:00

9e5b335f29 fix

Guillermo Venegas added 1 commit 2023-08-16 02:26:43 +02:00

afdd21aac5 add top and botton

Guillermo Venegas commented

2023-08-16 02:36:47 +02:00

I also included for the horizontal scroll bars, I can reverse it if necessary

I also included for the horizontal scroll bars, I can reverse it if necessary <video src="/attachments/1d791085-4d24-4a61-94ae-b514172bd73c" title="2023-08-15 18-27-42.mp4" controls></video>

2023-08-15 18-27-42.mp4

615 KiB

❤️ 1

Pablo Vazquez commented

2023-08-16 19:06:52 +02:00

@guishe thank you for the patience and working on this! Such a nice improvement.

Harley Acheson commented

2023-08-17 01:26:02 +02:00

Yes, this is the exact behavior we decided upon. Basically for the following three reasons:

We don't want to show change to the scrollbars where they can't be used
It shows a directionality hint; which side of the scroller it is influencing
Increased feedback for the crossing of regions

I also included for the horizontal scroll bars, I can reverse it if necessary

We definitely want this for both horizontal and vertical scrollbars.

Some of the tests for is_vertical and is_horizontal look unnecessary. Do we ever get a scroller that is on the right edge but is not vertical, or on the bottom and not horizontal? Or do these get out of sync or we don't set one or the other?

Unrelated to this patch (and a problem for a while), but related to scrolling, we should look at the user experience on the right side of tool bars. When a scrollbar is needed for those they take up the same position as the zone for dragging it wider and narrower. There are times when it is difficult to move the scroller because it wants to drag left/right instead. Again, not a problem introduced in this PR and not something I broke recently.

Yes, this is the exact behavior we decided upon. Basically for the following three reasons: * We don't want to show change to the scrollbars where they can't be used * It shows a directionality hint; which side of the scroller it is influencing * Increased feedback for the crossing of regions > I also included for the horizontal scroll bars, I can reverse it if necessary We definitely want this for both horizontal and vertical scrollbars. Some of the tests for is_vertical and is_horizontal look unnecessary. Do we ever get a scroller that is on the right edge but is not vertical, or on the bottom and not horizontal? Or do these get out of sync or we don't set one or the other? Unrelated to this patch (and a problem for a while), but related to scrolling, we should look at the user experience on the right side of tool bars. When a scrollbar is needed for those they take up the same position as the zone for dragging it wider and narrower. There are times when it is difficult to move the scroller because it wants to drag left/right instead. Again, not a problem introduced in this PR and not something I broke recently.

Harley Acheson requested review from Harley Acheson 2023-08-17 01:26:16 +02:00

Guillermo Venegas commented

2023-08-17 04:18:59 +02:00

Some of the tests for is_vertical and is_horizontal look unnecessary.

Some regions can have 2 scrollbars (like main in outliner), az->region->v2d.scroll tags where are the vertical and horizontal at the same time, its needed, action zones for scrollers only knows its orientations

Checking if AZEdge edge; can be used (cannot, is a union between AZEdge and AZScrollDirection)

>Some of the tests for is_vertical and is_horizontal look unnecessary. Some regions can have 2 scrollbars (like main in outliner), `az->region->v2d.scroll` tags where are the vertical and horizontal at the same time, its needed, action zones for scrollers only knows its orientations Checking if `AZEdge edge;` can be used (cannot, is a union between AZEdge and AZScrollDirection)

Guillermo Venegas added 1 commit 2023-08-17 05:16:45 +02:00

63d60c586e fix position interpretation

Guillermo Venegas commented

2023-08-17 05:19:10 +02:00

Updated the logic of the tests, the scrollbar az to be able to be at the top, first it should be a horizontal scrollbar az, etc.

Updated the logic of the tests, the scrollbar `az` to be able to be at the top, first it should be a horizontal scrollbar az, etc.

Harley Acheson referenced this pull request

2023-08-18 21:01:55 +02:00

Fix #111086: Ignore Scroller Zones in Invisible Regions #111126

Harley Acheson approved these changes 2023-08-22 00:45:25 +02:00

Harley Acheson left a comment

Awesome!