UI Experiment: Extended Screen Edge Movement #120998

Harley Acheson · 2024-04-23T21:51:47+02:00

Harley Acheson commented

2024-04-23 21:51:47 +02:00

Experiment allowing testing of widened hit width for editor edges,
highlighting of active edges.

This is NOT a proposal for any of the following. This is for testing two separate changes:

This increases the hit width of editor edges by about a line width on either side. This could potentially make it easier to resize areas for pen users. Testing for this is just to see if the change is noticeably better and if it interferes with other areas like scrollbars.
Separately this PR draws a highlight line on the active edge while dragging. Testing here is just to see if there is any merit to edge highlighting in this way. Some applications do this during edge movement and/or when hovering.

My own thoughts on this:

Wider move area hit width. I haven't found any time when this wider width interferes with anything else. But I have difficulty judging how much this improves area movement. It could be by a non-noticeable amount, it could be substantial, or I could be imagining it. Since I have no trouble with this now it is hard to tell the difference. I think its better, but maybe best judged by someone who already finds it finicky.

The edge highlight. I am surprised that I like this. I think because it acts as feedback that you are actually getting the action you think you initiated. You know you didn't click a "region disclosure" widget by accident, for example. Or when the moving edge is part of multiple editors it is clear that you are moving them all, not just the one you clicked on.

Experiment allowing testing of widened hit width for editor edges, highlighting of active edges. ---- This is NOT a proposal for any of the following. This is for testing two separate changes: 1. This increases the hit width of editor edges by about a line width on either side. This could potentially make it easier to resize areas for pen users. Testing for this is just to see if the change is noticeably better and if it interferes with other areas like scrollbars. 2. Separately this PR draws a highlight line on the active edge while dragging. Testing here is just to see if there is any merit to edge highlighting in this way. Some applications do this during edge movement and/or when hovering. ![Docking3.gif](/attachments/031a2ba4-b57d-478a-8483-e82bb7bd56d4) My own thoughts on this: Wider move area hit width. I haven't found any time when this wider width interferes with anything else. But I have difficulty judging how much this improves area movement. It could be by a non-noticeable amount, it could be substantial, or I could be imagining it. Since I have no trouble with this now it is hard to tell the difference. I think its better, but maybe best judged by someone who already finds it finicky. The edge highlight. I am surprised that I like this. I think because it acts as feedback that you are actually getting the action you think you initiated. You know you didn't click a "region disclosure" widget by accident, for example. Or when the moving edge is part of multiple editors it is clear that you are moving them all, not just the one you clicked on.

BlueEdge.gif

96 KiB

Harley Acheson added 1 commit 2024-04-23 21:51:57 +02:00

buildbot/vexp-code-patch-lint Build done. Details

buildbot/vexp-code-patch-darwin-arm64 Build done. Details

buildbot/vexp-code-patch-darwin-x86_64 Build done. Details

buildbot/vexp-code-patch-linux-x86_64 Build done. Details

buildbot/vexp-code-patch-windows-amd64 Build done. Details

buildbot/vexp-code-patch-coordinator Build done. Details

829f136011 UI Experiment: Extended Screen Edge Movement

Experiment allowing testing of widened hit width for editor edges,
highlighting of active edges, and extended hit area while holding Alt.

Harley Acheson added this to the User Interface project 2024-04-23 21:52:09 +02:00

Harley Acheson requested review from Pablo Vazquez 2024-04-23 21:52:16 +02:00

Hadrien commented

2024-04-24 20:52:14 +02:00

First-time contributor

Any chance a build can be triggered? the idea on paper reminds me of how GNOME allows to resize windows. I haven't used it in a while, but loved it back then.

Harley Acheson commented

2024-04-24 21:05:08 +02:00

@blender-bot package

Blender Bot commented

2024-04-24 21:05:12 +02:00

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR120998) when ready.

Harley Acheson commented

2024-04-24 23:20:53 +02:00

@HadrienBrissaud

Yes, there should be builds here: https://builder.blender.org/download/patch/PR120998/

But would love if you can test each of the three items shown in the first comment.

@HadrienBrissaud Yes, there should be builds here: https://builder.blender.org/download/patch/PR120998/ But would love if you can test each of the three items shown in the first comment.

Hadrien commented

2024-04-25 19:38:15 +02:00

First-time contributor

the extended hit width makes the edge easier to grab while otherwise not stepping on content, as far as I've observed. The sidebar "arrow" handle takes precedence over the edge, which is nice. It seems unlikely to be triggered by accident. Seems like an improvement.
concise bit of feedback, I like that blue line.
alt triggers the larger hit zone (as indicated by the cursor change), but the click won't register.
Anyhow, are you sure this doesn't conflict with other stuff? some interface elements can be right next to the editor's edge and alt is used in other situations, such as alt-clicking for multi-properties editing, or alt-clicking keyframes in the graph editor to select all keyframes on the same frame, etc. I couldn't actually find a case when this would conflict, especially since the actual action won't register in the build above. So I can't be sure if it would conflict over any one of these examples.

Generally, I think 3. is a bit superfluous 1. gives an appreciable comfort boost already.

1. the extended hit width makes the edge easier to grab while otherwise not stepping on content, as far as I've observed. The sidebar "arrow" handle takes precedence over the edge, which is nice. It seems unlikely to be triggered by accident. Seems like an improvement. 2. concise bit of feedback, I like that blue line. 3. alt triggers the larger hit zone (as indicated by the cursor change), but the click won't register. Anyhow, are you sure this doesn't conflict with other stuff? some interface elements can be right next to the editor's edge and alt is used in other situations, such as alt-clicking for multi-properties editing, or alt-clicking keyframes in the graph editor to select all keyframes on the same frame, etc. I couldn't actually find a case when this would conflict, especially since the actual action won't register in the build above. So I can't be sure if it would conflict over any one of these examples. Generally, I think 3. is a bit superfluous 1. gives an appreciable comfort boost already.

Harley Acheson commented

2024-04-25 19:56:42 +02:00

the extended hit width makes the edge easier to grab while otherwise not stepping on content, as far as I've observed. The sidebar "arrow" handle takes precedence over the edge, which is nice. It seems unlikely to be triggered by accident. Seems like an improvement.

Yes, I think so too but have a hard time quantifying it. As in it could be making it much easier or I could be imagining it all.

concise bit of feedback, I like that blue line.

I do too, but not sure why. I think it is that at the moment you start dragging it is a feedback that you are getting what you expected. You know you didn't accidentally drag a sidebar arrow for example. My brain also likes it when dragging an edge that is shared by multiple editors, in that it makes it clear that the entire shared edge is moving not just the one edge you have grabbed.

Generally, I think 3. is a bit superfluous 1. gives an appreciable comfort boost already.

True. We could possibly start with 1 see how that helps

> 1. the extended hit width makes the edge easier to grab while otherwise not stepping on content, as far as I've observed. The sidebar "arrow" handle takes precedence over the edge, which is nice. It seems unlikely to be triggered by accident. Seems like an improvement. Yes, I _think_ so too but have a hard time quantifying it. As in it could be making it much easier or I could be imagining it all. > 2. concise bit of feedback, I like that blue line. I do too, but not sure why. I think it is that at the moment you start dragging it is a feedback that you are getting what you expected. You know you didn't accidentally drag a sidebar arrow for example. My brain also likes it when dragging an edge that is shared by multiple editors, in that it makes it clear that the entire shared edge is moving not just the one edge you have grabbed. > Generally, I think 3. is a bit superfluous 1. gives an appreciable comfort boost already. True. We could possibly start with 1 see how that helps

Harley Acheson added 1 commit 2024-04-25 20:44:25 +02:00

750fe643cb Remove extended edge grab. add error checking for top and bottom global edges. theme color.

Harley Acheson added 1 commit 2024-04-25 20:46:06 +02:00

17d7060532 unintended whitespace change

Harley Acheson added 2 commits 2024-04-28 06:01:10 +02:00

e727d386ee Merge branch 'main' of projects.blender.org:blender/blender into ExtendedEdgeMove

ccb892efb9 Cleanup. Nicer line.

This pull request can be merged automatically.

This branch is out-of-date with the base branch

You are not authorized to merge this pull request.

View command line instructions.