blender
/
blender
129
398
Fork 572
Code Issues 6.2k Pull Requests 750 Projects 19 Wiki Activity

WIP: VSE Experiment in Mouse Cursor and Transform Status Feedback #107950

Draft
Harley Acheson wants to merge 1 commits from Harley/blender:SequencerCursor into main
pull from: Harley/blender:SequencerCursor
merge into: blender:main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Conversation 26 Commits 1 Files Changed 2 +108 -30
Harley Acheson commented 2023-05-15 20:17:00 +02:00
Member
Copy Link

Experiment that changes mouse cursor on hover of strip parts for better
feedback. Also changes to when handles are drawn.

Just something to test to see if we like any of this, or just to help decide what is not wanted. While consulting with Brad Clark he identified some problems with communicating potential operations on VSE strips.

Currently there is no change to the mouse cursor when you hover over any parts of strips. So no indication that dragging or resizing is possible before doing so. One of this PR's primary changes is to show the mouse cursor as WM_CURSOR_X_MOVE at the right and left edges, and as WM_CURSOR_NSEW_SCROLL in the body when applicable.

A common complaint is operation confusion when handles are selected. This PR separates these two modes. When moving handles only handles are shown as selected, but outlining of the strip itself is only done during strip movement mode.

Currently when transforming strips we show the outline in red when overlapping. This PR extends this to show handle overlapping differently from strip movement overlap.

VSEFeedback.gif

Experiment that changes mouse cursor on hover of strip parts for better feedback. Also changes to when handles are drawn. --- Just something to test to see if we like any of this, or just to help decide what is not wanted. While consulting with Brad Clark he identified some problems with communicating potential operations on VSE strips. Currently there is no change to the mouse cursor when you hover over any parts of strips. So no indication that dragging or resizing is possible before doing so. One of this PR's primary changes is to show the mouse cursor as WM_CURSOR_X_MOVE at the right and left edges, and as WM_CURSOR_NSEW_SCROLL in the body when applicable. A [common complaint](https://archive.blender.org/developer/maniphest/0090/0090843/index.html) is operation confusion when handles are selected. This PR separates these two modes. When moving handles only handles are shown as selected, but outlining of the strip itself is only done during strip movement mode. Currently when transforming strips we show the outline in red when overlapping. This PR extends this to show handle overlapping differently from strip movement overlap. ![VSEFeedback.gif](/attachments/de6052fc-8477-4f86-b8f5-21cf471e70cc)
VSEFeedback.gif
196 KiB
❤️ 12 🎉 8
Harley Acheson added this to the Video Sequencer project 2023-05-15 20:17:53 +02:00
Harley Acheson modified the project from Video Sequencer to Animation & Rigging 2023-05-15 20:23:08 +02:00
Harley Acheson modified the project from Animation & Rigging to Video Sequencer 2023-05-15 20:23:18 +02:00
Harley Acheson added the
Interest
Animation & Rigging
 label 2023-05-15 20:23:57 +02:00
Sergey Sharybin commented 2023-05-17 09:15:47 +02:00
Owner
Copy Link

I am not sure if this is something you consider ready for the review.

As a technical exercise this seems interesting.

On a practical level, if I am not mistaken, this only works as expected when using LMB selection, and will give misleading results when using RMB selection.

Before moving towards with this feature, it would be very nice to first agree on the design, in particular:

  • How does it integrate with LMB and RMB selection presets?
  • How does it integrate with the handle selection, without starting to compete with the current way of interaction?
I am not sure if this is something you consider ready for the review. As a technical exercise this seems interesting. On a practical level, if I am not mistaken, this only works as expected when using LMB selection, and will give misleading results when using RMB selection. Before moving towards with this feature, it would be very nice to first agree on the design, in particular: - How does it integrate with LMB and RMB selection presets? - How does it integrate with the handle selection, without starting to compete with the current way of interaction?
Sergey Sharybin reviewed 2023-05-17 09:20:54 +02:00
source/blender/editors/space_sequencer/space_sequencer.c Outdated
@ -673,0 +693,4 @@
float pixelx = BLI_rctf_size_x(&v2d->cur) / BLI_rcti_size_x(&v2d->mask);
rctf rectf;
LISTBASE_FOREACH (Sequence *, seq, ed->seqbasep) {
Sergey Sharybin commented 2023-05-17 09:20:51 +02:00
Owner
Copy Link

Correct me if I'm wrong, but this runs on every mouse move? On a production edit it could end up in rather expensive loop.

Also, if you're zoomed out in such edits it could be quite noisy to change cursor on hover of a tiny strips.

Correct me if I'm wrong, but this runs on every mouse move? On a production edit it could end up in rather expensive loop. Also, if you're zoomed out in such edits it could be quite noisy to change cursor on hover of a tiny strips.
Richard Antalik commented 2023-05-18 20:45:59 +02:00
Member
Copy Link

At some point I wanted to implement managed selection for VSE, so looping over many strips would not be necessary. That idea came across my mind multiple times and could simplify/improve some features still, so could be used for feature like this as well.

At some point I wanted to implement managed selection for VSE, so looping over many strips would not be necessary. That idea came across my mind multiple times and could simplify/improve some features still, so could be used for feature like this as well.
Harley Acheson commented 2023-05-17 16:56:23 +02:00
Author
Member
Copy Link

I am not sure if this is something you consider ready for the review.

No, not at all. But I should have included "WIP", not just "Experiment" to make this more clear. As mentioned in the original comment "Just something to test to see if we like any of this, or just to help decide what is not wanted."

This is currently being discussed within the Modelling and VSE Modules.

> I am not sure if this is something you consider ready for the review. No, not at all. But I should have included "WIP", not just "Experiment" to make this more clear. As mentioned in the original comment "Just something to test to see if we like any of this, or just to help decide what is not wanted." This is currently being discussed within the Modelling and VSE Modules.
Harley Acheson changed title from VSE: Experiment: Mouse Cursor and Transform Status Feedback to WIP: VSE Experiment in Mouse Cursor and Transform Status Feedback 2023-05-17 16:56:50 +02:00
Brad Clark commented 2023-05-17 23:10:41 +02:00
Member
Copy Link

"How does it integrate with LMB and RMB selection presets?"

ohhh good point and another layer to think about and understand how it impacts things. Thanks for the notes.

"How does it integrate with LMB and RMB selection presets?" ohhh good point and another layer to think about and understand how it impacts things. Thanks for the notes.
Harley Acheson commented 2023-05-17 23:30:32 +02:00
Author
Member
Copy Link

@BClark

I'm not understanding the "How does it integrate with LMB and RMB selection presets" question since this does not change interaction, but only changes how the mouse cursor looks during those interactions. Am I missing something?

@BClark I'm not understanding the "How does it integrate with LMB and RMB selection presets" question since this does not change interaction, but only changes how the mouse cursor looks during those interactions. Am I missing something?
Brad Clark commented 2023-05-18 00:37:12 +02:00
Member
Copy Link

No you are right, reading it again it shouldn't matter... but it did make me think about when it might.
For the issue of extreme zoom where everything is too tiny to roll over and get an edge, I don't know..
At a small enough size right now, the handles are drawn and show still but you can't click on them so it just tricks you into thinking you can grab them when you can't and you would not be trying to do trim edits like that zoomed so far out anyway, at least I wouldn't.

No you are right, reading it again it shouldn't matter... but it did make me think about when it might. For the issue of extreme zoom where everything is too tiny to roll over and get an edge, I don't know.. At a small enough size right now, the handles are drawn and show still but you can't click on them so it just tricks you into thinking you can grab them when you can't and you would not be trying to do trim edits like that zoomed so far out anyway, at least I wouldn't.
Richard Antalik commented 2023-05-18 20:47:22 +02:00
Member
Copy Link

I agree with Sergeys noise concerns. personally I wouldn't use NSWE cursor at all. Also I would rather make handles invisible by default and highlight them on hover / selection without changing cursor. IMO users (should) know what to expect when clicking and dragging when there is no ambiguity.

I think @fsiddi had some ideas on how to improve current handles too, so perhaps he can outline his vision.

I agree with Sergeys noise concerns. personally I wouldn't use NSWE cursor at all. Also I would rather make handles invisible by default and highlight them on hover / selection without changing cursor. IMO users (should) know what to expect when clicking and dragging when there is no ambiguity. I think @fsiddi had some ideas on how to improve current handles too, so perhaps he can outline his vision.
tintwotin commented 2023-05-19 07:54:49 +02:00
First-time contributor
Copy Link

Changing the mouse cursor is an excellent and industry standard way of indicating to users what will happen if they click. Without these, users will accidentally end up doing unintended operations. Ex. moving handles when they want to move the strip and vice versa. So, this is very helpful for a UI like a NLE where a lot of different operators can be executed, depending on the mouse position. This saves the user from a lot of unnecessary clicks to change tool etc. Here is KDEnlive as an example of the cursor in use(their design have other problems, though) attached.

By the cursor change, the cursor is also indicating that the handle is clickable, without the handle needs to cover part of the strip, so this can also work as a solution for the current problem of handles permanently covering part of the strip, so you can't see ex. the waveform at the position of the cut. There still needs to be some kind of handle indication, for when transforming the timings of several strips, though.

In the KDENlive example, the mouse cursor can also help users distinguish between handle transforming and manipulating fades, which are pretty much located in the very same area. So, when the elements are very close or strips are small (zoomed out timeline), the cursor change will tell you what you're doing when you actually can't see what you're clicking.

So, for me, are mouse cursor changes essential for improving the UX of the animation editors, including the VSE.

Changing the mouse cursor is an excellent and industry standard way of indicating to users what will happen if they click. Without these, users will accidentally end up doing unintended operations. Ex. moving handles when they want to move the strip and vice versa. So, this is very helpful for a UI like a NLE where a lot of different operators can be executed, depending on the mouse position. This saves the user from a lot of unnecessary clicks to change tool etc. Here is KDEnlive as an example of the cursor in use(their design have other problems, though) attached. By the cursor change, the cursor is also indicating that the handle is clickable, without the handle needs to cover part of the strip, so this can also work as a solution for the current problem of handles permanently covering part of the strip, so you can't see ex. the waveform at the position of the cut. There still needs to be some kind of handle indication, for when transforming the timings of several strips, though. In the KDENlive example, the mouse cursor can also help users distinguish between handle transforming and manipulating fades, which are pretty much located in the very same area. So, when the elements are very close or strips are small (zoomed out timeline), the cursor change will tell you what you're doing when you actually can't see what you're clicking. So, for me, are mouse cursor changes essential for improving the UX of the animation editors, including the VSE.
mouse_cursor_kdenlive.gif
222 KiB
mouse_cursor_kdenlive.gif
👍 1
Brad Clark commented 2023-05-20 06:05:09 +02:00
Member
Copy Link

" IMO users (should) know what to expect when clicking and dragging when there is no ambiguity."

Without cursor change feedback, there is always ambiguity because you don't know what mode you are in when you have already selected something and you don't always know if the hit area is clickable. Having only invisible handles is a discovery method but because the handles could do more than just translate the start/end of a clip, having the cursor change provides two layers of feedback and maintains user awareness that they have in fact made a selection.

Both things are issues as it stands now. No way to know that you have a selection on a handle active if you have moved the view because you think/cursor tells you by looking the same as moving a clip... creating doubt.
Even this webpage when you roll over areas that can be clicked, image not only do you get an underline (visual change on the click area for links, you get a cursor change to a pointer finger and you get a roll over text as a 3rd feedback device for accessibility to click it.

Cursor change is widely used and expected and the clearest/fastest way to set user expectation to what will happen when the click.

" IMO users (should) know what to expect when clicking and dragging when there is no ambiguity." Without cursor change feedback, there is always ambiguity because you don't know what mode you are in when you have already selected something and you don't always know if the hit area is clickable. Having only invisible handles is a discovery method but because the handles could do more than just translate the start/end of a clip, having the cursor change provides two layers of feedback and maintains user awareness that they have in fact made a selection. Both things are issues as it stands now. No way to know that you have a selection on a handle active if you have moved the view because you think/cursor tells you by looking the same as moving a clip... creating doubt. Even this webpage when you roll over areas that can be clicked, ![image](/attachments/010b5e83-4f32-4c72-8649-b93328daa176) not only do you get an underline (visual change on the click area for links, you get a cursor change to a pointer finger and you get a roll over text as a 3rd feedback device for accessibility to click it. Cursor change is widely used and expected and the clearest/fastest way to set user expectation to what will happen when the click.
image.png
3.4 KiB
Sergey Sharybin commented 2023-05-22 15:55:32 +02:00
Owner
Copy Link

@BClark

I'm not understanding the "How does it integrate with LMB and RMB selection presets" question since this does not change interaction, but only changes how the mouse cursor looks during those interactions. Am I missing something?

If it is only the cursor shape changes, then with the standard Blender keymap the interaction is confusing: the cursor has changed its shape (suggesting it is ready to resize the strip), but once you do LMB click-drag you move the playhead instead of resizing the strip,

> @BClark > > I'm not understanding the "How does it integrate with LMB and RMB selection presets" question since this does not change interaction, but only changes how the mouse cursor looks during those interactions. Am I missing something? > > If it is only the cursor shape changes, then with the standard Blender keymap the interaction is confusing: the cursor has changed its shape (suggesting it is ready to resize the strip), but once you do LMB click-drag you move the playhead instead of resizing the strip,
Brad Clark commented 2023-05-22 16:23:00 +02:00
Member
Copy Link

Yes, I see, that is true in some cases, but not all.

While you could first have the rollover feedback be a visual change on the handle (it appearing like how scroll bars work now) and then once clicked change the cursor so you know you are ready to move would be

But this isn't always the case in Blender, for example when you roll over a window split edge in the UI it changes to to a drag cursor first then you have to click and drag and the same over the frame start/end/current frame.

So for example changing frame start/or current frame.. it only shows the frame number until you roll over it then you get two clickable arrows that show up and the cursor changes to show you that when you click, you are going to be translating it.

The difference is that those cases are a click, act, release and not an active selection like handles are, but the UI interaction as it is now in this patch, exists all over Blender.

Yes, I see, that is true in some cases, but not all. While you could first have the rollover feedback be a visual change on the handle (it appearing like how scroll bars work now) and then once clicked change the cursor so you know you are ready to move would be But this isn't always the case in Blender, for example when you roll over a window split edge in the UI it changes to to a drag cursor first then you have to click and drag and the same over the frame start/end/current frame. So for example changing frame start/or current frame.. it only shows the frame number until you roll over it then you get two clickable arrows that show up and the cursor changes to show you that when you click, you are going to be translating it. The difference is that those cases are a click, act, release and not an active selection like handles are, but the UI interaction as it is now in this patch, exists all over Blender.
Harley Acheson commented 2023-05-22 16:41:47 +02:00
Author
Member
Copy Link

If it is only the cursor shape changes, then with the standard Blender keymap the interaction is confusing: the cursor has changed its shape (suggesting it is ready to resize the strip), but once you do LMB click-drag you move the playhead instead of resizing the strip,

Ouch. Thanks for clarifying.

Now it is also looking odd that in Node editors we still move nodes and resize them with left mouse dragging while in Right select mode.

> If it is only the cursor shape changes, then with the standard Blender keymap the interaction is confusing: the cursor has changed its shape (suggesting it is ready to resize the strip), but once you do LMB click-drag you move the playhead instead of resizing the strip, Ouch. Thanks for clarifying. Now it is also looking odd that in Node editors we still move nodes and resize them with left mouse dragging while in Right select mode.
tintwotin commented 2023-05-22 17:24:18 +02:00
First-time contributor
Copy Link

AFAIK, are the only ways to change the playhead position in left click mode in the VSE by click drag in the ruler or shift+right click drag. So, in the first case the mouse will never be over a strip when dragging playhead and in the second case(shift+rc) the cursor change should be canceled - in right click mode (if that still exists?) that would of course be reversed behavior. I'm not sure why this is an argument for not changing the cursor on hover?

AFAIK, are the only ways to change the playhead position in left click mode in the VSE by click drag in the ruler or shift+right click drag. So, in the first case the mouse will never be over a strip when dragging playhead and in the second case(shift+rc) the cursor change should be canceled - in right click mode (if that still exists?) that would of course be reversed behavior. I'm not sure why this is an argument for not changing the cursor on hover?
Harley Acheson commented 2023-05-22 17:31:11 +02:00
Author
Member
Copy Link

AFAIK...in right click mode (if that still exists?) that would of course be reversed behavior. I'm not sure why this is an argument for not changing the cursor on hover?

Right-click select mode still exists and the described behavior is easy to test. Just go to Preferences / Keymap. At the top change "Select with Mouse Button" to "Right".

Now clicking the LEFT mouse button anywhere in the body, or at the edge, of a strip will move the playhead. So having the hovering mouse cursor imply what happens when you drag with the RIGHT mouse button feels wrong.

> AFAIK...in right click mode (if that still exists?) that would of course be reversed behavior. I'm not sure why this is an argument for not changing the cursor on hover? Right-click select mode still exists and the described behavior is easy to test. Just go to Preferences / Keymap. At the top change "Select with Mouse Button" to "Right". Now clicking the LEFT mouse button anywhere in the body, or at the edge, of a strip will move the playhead. So having the hovering mouse cursor imply what happens when you drag with the RIGHT mouse button feels wrong.
👍 2
tintwotin commented 2023-05-22 17:46:09 +02:00
First-time contributor
Copy Link

I guess right-clicking should cancel out on the cursor change in general, then?

I guess right-clicking should cancel out on the cursor change in general, then?
Harley Acheson commented 2023-05-22 18:15:39 +02:00
Author
Member
Copy Link

I guess right-clicking should cancel out on the cursor change in general, then?

Do you mean just not do this mouse cursor stuff if the user has chosen right-click select? That is possible but would need some thought. As this PR shows, having this extra mouse cursor feedback allows simplifying some of the handle drawing too and you wouldn't want that to differ between select modes.

Or you could consider larger interaction changes for 4.0. As mentioned, with Node Editors you can change to right-click select and afterward you can drag nodes around with either button. Box select with either button. Resizing is done with left-drag. The mouse cursor changes exactly as this PR.

In the following all the interaction is done with the left mouse even though it is right-click select:

NodeRightClick.gif

> I guess right-clicking should cancel out on the cursor change in general, then? Do you mean just not do this mouse cursor stuff if the user has chosen right-click select? That is possible but would need some thought. As this PR shows, having this extra mouse cursor feedback allows simplifying some of the handle drawing too and you wouldn't want that to differ between select modes. Or you could consider larger interaction changes for 4.0. As mentioned, with Node Editors you can change to right-click select and afterward you can drag nodes around with either button. Box select with either button. Resizing is done with left-drag. The mouse cursor changes exactly as this PR. In the following all the interaction is done with the left mouse even though it is right-click select: ![NodeRightClick.gif](/attachments/1c376748-f063-4079-b867-a5b38b2f2d37)
NodeRightClick.gif
94 KiB
Francesco Siddi commented 2023-05-23 01:40:42 +02:00
Member
Copy Link

Thanks for the efforts in this area, Harley. Here are the suggested next steps for this patch:

  • ensure interaction works as expected with RCS (when drawing the trim cursor, left click should trigger resizing)
  • when trimming, do not draw the strip handle
  • implement strip handles as an overlay (on by default for now)
  • design a more expressive cursor that hints which strip will be trimmed when there are two adjacent strips
  • ensure that resizing works on multiple strips
Thanks for the efforts in this area, Harley. Here are the suggested next steps for this patch: - [ ] ensure interaction works as expected with RCS (when drawing the trim cursor, left click should trigger resizing) - [ ] when trimming, do not draw the strip handle - [ ] implement strip handles as an overlay (on by default for now) - [ ] design a more expressive cursor that hints which strip will be trimmed when there are two adjacent strips - [ ] ensure that resizing works on multiple strips
Harley Acheson commented 2023-05-29 04:26:26 +02:00
Author
Member
Copy Link

I'm frankly not seeing anything in this experiment that is useful. The spoiler seems to be RCS.

Mouse cursor change only helps in indicating potential operations with the left mouse button. With those in place it does improve the feedback enough to consider making changes to the drawing of strips and handles. Handles could be drawn differently or not at all in some circumstances. We could even consider highlighting only the handles or only the strip, to better indicate these two modes.

But these same things can't be considered with RCS since we don't have the added feedback of mouse cursor changes. And I wouldn't want RCS and LCS to diverge to the point where they are drawn differently.

So just not seeing this as a workable path toward any improvement. Unless someone can convince me otherwise, but that would require quite detailed prototyping all the modes and processes in both LCS and RCS.

I'm frankly not seeing anything in this experiment that is useful. The spoiler seems to be RCS. Mouse cursor change only helps in indicating potential operations with the left mouse button. With those in place it does improve the feedback enough to consider making changes to the drawing of strips and handles. Handles could be drawn differently or not at all in some circumstances. We could even consider highlighting only the handles or only the strip, to better indicate these two modes. But these same things can't be considered with RCS since we don't have the added feedback of mouse cursor changes. And I wouldn't want RCS and LCS to diverge to the point where they are drawn differently. So just not seeing this as a workable path toward any improvement. Unless someone can convince me otherwise, but that would require quite detailed prototyping all the modes and processes in both LCS and RCS.
Brad Clark commented 2023-05-29 05:52:27 +02:00
Member
Copy Link

"Mouse cursor change only helps in indicating potential operations with the left mouse button"

Trying this out with RCS I am not clear on the issue but as you said something is different I am guessing in the code that makes it harder?

The cursor change once you are interacting though I still think is of benefit, showing that if I have a handle selected and I go to move it, that it is only a left/right cursor not a 4 way drag still will help I feel like.

"Mouse cursor change only helps in indicating potential operations with the left mouse button" Trying this out with RCS I am not clear on the issue but as you said something is different I am guessing in the code that makes it harder? The cursor change once you are interacting though I still think is of benefit, showing that if I have a handle selected and I go to move it, that it is only a left/right cursor not a 4 way drag still will help I feel like.
Harley Acheson commented 2023-05-29 06:09:26 +02:00
Author
Member
Copy Link

Trying this out with RCS I am not clear on the issue

With a mouse you can depress any of three or more buttons and drag around. But changes to the mouse cursor is meant to show only what happens when you use the left mouse button. With RCS the left mouse operation is to change the frame, while right mouse button drags the clip or handles.

> Trying this out with RCS I am not clear on the issue With a mouse you can depress any of three or more buttons and drag around. But changes to the mouse cursor is meant to show only what happens when you use the **left** mouse button. With RCS the left mouse operation is to change the frame, while right mouse button drags the clip or handles.
tintwotin commented 2023-05-29 07:22:26 +02:00
First-time contributor
Copy Link

But changes to the mouse cursor is meant to show only what happens when you use the left mouse button.

In right click select mode, the cursor should indicate what happens when the right button is clicked. That is the only thing which makes sense to me. In RCS, all functionally needs to be moved to the other mouse button, including mouse cursor change.

Are you saying that this is impossible(too much trouble) to do the mouse cursor changes differently when in right click select mode? Or the RCS mode needs to go before this industry standard feature can be implemented?

> But changes to the mouse cursor is meant to show only what happens when you use the left mouse button. In right click select mode, the cursor should indicate what happens when the **right** button is clicked. That is the only thing which makes sense to me. In RCS, all functionally needs to be moved to the other mouse button, including mouse cursor change. Are you saying that this is impossible(too much trouble) to do the mouse cursor changes differently when in right click select mode? Or the RCS mode needs to go before this industry standard feature can be implemented?
Harley Acheson commented 2023-05-29 17:15:25 +02:00
Author
Member
Copy Link

In right click select mode, the cursor should indicate what happens when the right button is clicked. That is the only thing which makes sense to me. In RCS, all functionally needs to be moved to the other mouse button, including mouse cursor change.

RCS is an interaction pattern, not an OS-level "swap left and right buttons" change. Both the primary mouse button and secondary have actions, it is just that the secondary is used for selecting items. Mostly - it is a bit flawed as an interaction model. But the primary button remains the primary button, we just use it in an unintuitive way. We would subvert user expectations even further by having mouse cursor changes based on potential actions of the secondary button.

> In right click select mode, the cursor should indicate what happens when the **right** button is clicked. That is the only thing which makes sense to me. In RCS, all functionally needs to be moved to the other mouse button, including mouse cursor change. RCS is an interaction pattern, not an OS-level "swap left and right buttons" change. Both the primary mouse button and secondary have actions, it is just that the secondary is used for selecting items. Mostly - it is a bit flawed as an interaction model. But the primary button remains the primary button, we just use it in an unintuitive way. We would subvert user expectations even further by having mouse cursor changes based on potential actions of the secondary button.
Nika Kutsniashvili commented 2023-05-30 01:12:47 +02:00
Contributor
Copy Link

So the vast majority of Blender users are gonna miss out on a nice feature because some folks are using a niche feature that should've been retired years ago and now if they can't have it nobody will

So the vast majority of Blender users are gonna miss out on a nice feature because some folks are using a niche feature that should've been retired years ago and now if they can't have it nobody will
Harley Acheson commented 2023-05-30 01:36:47 +02:00
Author
Member
Copy Link

So the vast majority of Blender users are gonna miss out on a nice feature because some folks are using a niche feature that should've been retired years ago and now if they can't have it nobody will

No, there are possible options, but they are only things for the VSE module to consider, not for me to impose on them. They could remove the RCS interaction in VSE. They could change how RCS interaction works in VSE. They could choose to have RCS and LCS radically diverge.

But, as mentioned by others like @Sergey, this PR would be a breaking change for RCS users, which I didn't notice when creating it. I'm not seeing a way forward without changes being carefully considered by the VSE module.

> So the vast majority of Blender users are gonna miss out on a nice feature because some folks are using a niche feature that should've been retired years ago and now if they can't have it nobody will No, there are possible options, but they are only things for the VSE module to consider, not for me to impose on them. They could remove the RCS interaction in VSE. They could change how RCS interaction works in VSE. They could choose to have RCS and LCS radically diverge. But, as mentioned by others like @Sergey, this PR would be a breaking change for RCS users, which I didn't notice when creating it. I'm not seeing a way forward without changes being carefully considered by the VSE module.
Sergey Sharybin commented 2023-05-30 11:12:54 +02:00
Owner
Copy Link

It kind of goes beyond of the VSE module. In such topics the VSE module have to comply to an overall design of interaction with the software.

It kind of goes beyond of the VSE module. In such topics the VSE module have to comply to an overall design of interaction with the software.
tintwotin commented 2023-05-30 12:59:30 +02:00
First-time contributor
Copy Link

When comparing the RCS mode of the VSE with the RCS of the sculpt tool, it becomes clear that the VSE RCS is pretty weird(aka. inconsistent with that tool).

In RCS in the VSE left click only changes the playhead position, and right click does everything left click does in LCS mode.

In RCS in sculpt mode, right click grabs the object, and in LCS right click opens a menu. However, in both modes, the left click does the sculpting.

It is interesting to compare the VSE with the Sculpt mode, since it's got a hover - gizmo change function, which indicates what will happen if you left-click at that position, in the same way as the VSE mouse cursor change will.

If the VSE should work the same way as the sculpt tool, the left click functions should stay on left click, and right click could become ex. frame change in RCS mode. (Btw. as I remember it, the design of the RCS mode of the VSE was never really solved, but just left behind and forgotten about).

(In the video, the pop-up preferences don't show, but I'm changing to RCS)

When comparing the RCS mode of the VSE with the RCS of the sculpt tool, it becomes clear that the VSE RCS is pretty weird(aka. inconsistent with that tool). In RCS in the VSE left click only changes the playhead position, and right click does everything left click does in LCS mode. In RCS in sculpt mode, right click grabs the object, and in LCS right click opens a menu. However, in both modes, the left click does the sculpting. It is interesting to compare the VSE with the Sculpt mode, since it's got a hover - gizmo change function, which indicates what will happen if you left-click at that position, in the same way as the VSE mouse cursor change will. If the VSE should work the same way as the sculpt tool, the left click functions should stay on left click, and right click could become ex. frame change in RCS mode. (Btw. as I remember it, the design of the RCS mode of the VSE was never really solved, but just left behind and forgotten about). (In the video, the pop-up preferences don't show, but I'm changing to RCS)
Blender 2023-05-30 12-41-36.mp4
6.4 MiB
Brad Clark commented 2023-05-31 21:12:35 +02:00
Member
Copy Link

So after reading this and talking it over more the less and less I think the comment by @Sergey about expecting that left click should move the clip in the vse because the cursor is changed makes sense and here is why.

The user has already agreed by choice to use the RCS interaction mode & the RCS mode for any timeline -animation- type editor across blender that the left mouse button will move the playhead to the current frame and scrub while any transformation and selection of keys will happen with the right click.

So with that, if a user gets visual feedback in an time editing tool ( VSE, NLA, Timeline) through a cursor change showing what will happen when the user clicks and drags ( in their chosen interaction model) that they will be able to click and drag /transform the handle left and right and not move the entire clip.

The fact that the user through both by choice to use RCS mode and the fact that the RCS mode already breaks any normal convention for left click being the primary transform interaction method in any timeline tool in Blender, the expectations are already set and agreed.

This just provides proper feedback of what can happen when they click and what mode they are after they clicked and dragged.

Making the action and visual feedback consistent between RCS LCS existing Blender UI interaction.

So after reading this and talking it over more the less and less I think the comment by @Sergey about expecting that left click should move the clip in the vse because the cursor is changed makes sense and here is why. The user has already agreed by choice to use the RCS interaction mode & the RCS mode for any timeline -animation- type editor across blender that the left mouse button will move the playhead to the current frame and scrub while any transformation and selection of keys will happen with the right click. So with that, if a user gets visual feedback in an time editing tool ( VSE, NLA, Timeline) through a cursor change showing what will happen when the user clicks and drags ( in their chosen interaction model) that they will be able to click and drag /transform the handle left and right and not move the entire clip. The fact that the user through both by choice to use RCS mode and the fact that the RCS mode already breaks any normal convention for left click being the primary transform interaction method in any timeline tool in Blender, the expectations are already set and agreed. This just provides proper feedback of what can happen when they click and what mode they are after they clicked and dragged. Making the action and visual feedback consistent between RCS LCS existing Blender UI interaction.
Harley Acheson force-pushed SequencerCursor from 06ba4c14f3 to 96d5159655 2023-06-03 18:13:13 +02:00 Compare
This pull request has changes conflicting with the target branch.
  • source/blender/editors/space_sequencer/sequencer_draw.c
  • source/blender/editors/space_sequencer/space_sequencer.c
View command line instructions.

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u SequencerCursor:Harley-SequencerCursor
git checkout Harley-SequencerCursor
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
Interest
Alembic

  
Interest
Animation & Rigging

  
Interest
Asset Browser

  
Interest
Asset Browser Project Overview

  
Interest
Audio

  
Interest
Automated Testing

  
Interest
Blender Asset Bundle

  
Interest
BlendFile

  
Interest
Collada

  
Interest
Compatibility
This issue affects/is about backward or forward compatibility

  
Interest
Compositing

  
Interest
Core

  
Interest
Cycles

  
Interest
Dependency Graph

  
Interest
Development Management

  
Interest
EEVEE

  
Interest
EEVEE & Viewport

  
Interest
Freestyle

  
Interest
Geometry Nodes

  
Interest
Grease Pencil

  
Interest
ID Management

  
Interest
Images & Movies

  
Interest
Import Export

  
Interest
Line Art

  
Interest
Masking

  
Interest
Metal

  
Interest
Modeling

  
Interest
Modifiers

  
Interest
Motion Tracking

  
Interest
Nodes & Physics

  
Interest
OpenGL

  
Interest
Overlay

  
Interest
Overrides

  
Interest
Performance

  
Interest
Physics

  
Interest
Pipeline, Assets & IO

  
Interest
Platforms, Builds & Tests

  
Interest
Python API

  
Interest
Render & Cycles

  
Interest
Render Pipeline

  
Interest
Sculpt, Paint & Texture

  
Interest
Text Editor

  
Interest
Translations

  
Interest
Triaging

  
Interest
Undo

  
Interest
USD

  
Interest
User Interface

  
Interest
UV Editing

  
Interest
VFX & Video

  
Interest
Video Sequencer

  
Interest
Virtual Reality

  
Interest
Vulkan

  
Interest
Wayland
Issues relating to Wayland windowing support.

  
Interest
Workbench

  
Interest: X11

Issues relating to Xorg/X11 support.

  
Legacy
Blender 2.8 Project

  
Legacy
Milestone 1: Basic, Local Asset Browser

  
Legacy
OpenGL Error

  
Meta
Good First Issue

  
Meta
Papercut

  
Meta
Retrospective

  
Meta
Security
Issues relating to security: https://wiki.blender.org/wiki/Process/Vulnerability_Reports

  
Module
Animation & Rigging

  
Module
Core

  
Module
Development Management

  
Module
EEVEE & Viewport

  
Module
Grease Pencil

  
Module
Modeling

  
Module
Nodes & Physics

  
Module
Pipeline, Assets & IO

  
Module
Platforms, Builds & Tests

  
Module
Python API

  
Module
Render & Cycles

  
Module
Sculpt, Paint & Texture

  
Module
Triaging

  
Module
User Interface

  
Module
VFX & Video

  
Platform
FreeBSD

  
Platform
Linux

  
Platform
macOS

  
Platform
Windows

  
Priority
High

  
Priority
Low

  
Priority
Normal

  
Priority
Unbreak Now!

  
Status
Archived

  
Status
Confirmed

  
Status
Duplicate

  
Status
Needs Info from Developers

  
Status
Needs Information from User

  
Status
Needs Triage

  
Status
Resolved

  
Type
Bug

  
Type
Design

  
Type
Known Issue

  
Type
Patch

  
Type
Report

  
Type
To Do

No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Video Sequencer
Assignees
Clear assignees
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#107950
No description provided.
Delete Branch "Harley/blender:SequencerCursor"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?