I did. But I noticed that it’s not constant. Sometimes the handle will un-snap when slightly deviating from the axis, sometimes it can move a lot more without un-snapping.
1 Like
Yes, that’s what I’m getting. Seems to be a little erratic.
Those times are when you go back to where you started. The snapping direction (horizontal/vertical) is based on which direction you have moved the most from where you started (pressed the mouse button). Maybe it is unexpected to you because you forgot where you started from?
Shift is used to allow dragging from anywhere within the rectangle.
Alt is used to suspend snapping
I wish I could have used the same modifiers that we use to constrain the direction of keyframes.
You can see the previous discussion here:
Hi @brian, I’m not totally sure of what you mean by that… I’m trying to move the object with one continuous movement, vertically. At no point did I go back to where I started. Maybe I’ve missed something…
Yes, I did realise that. In my demo, it works fine for quite a while… maybe then at some point I inadvertently moved horizontally more than vertically without trying to, and the object jumped horizontally because of this. I will practice then and see if there is a technique to it - but the object does seem to jump horizontally (unwanted) quite easily. Just wondering if you find that?
PS I’m not complaining - it’s a huge improvement. 
Sure, I understand the problem there.
After further testing…
I found that moving an object in shorter bursts, rather than in one long movement) seems to help. See demo video below (no audio). Cool.
Also, I felt that using CTRL + SHIFT (allowing me to drag from anywhere inside the object) did seem to help too, although that may be psychological…
Yes you did. Watch your video again.
This is where you started:
Then, you moved it down:
Then, without ever releasing the mouse, you moved it back up where it “glitched” when you moved your mouse to the left relative to where you started from.
Yes. That makes perfect sense. Because each time you release the mouse and re-click, that resets the mouse starting point.
3 Likes
Oh of course you are right @brian. I had forgotten I changed direction in the video without releasing the mouse and/or the CTRL /SHIFT modifiers - I did that just to show it worked in some cases… I see the issue clearer now and you have solved it…
Just tested again and it works reliably if I just move in one direction. Thanks for clarifying it and apologies for my confusion!
PS congrats for some really neat programming for this feature. A neat solution, getting Shotcut to calculate the snapping direction (horizontal/vertical) based on which direction the user has moved the most from where they started.
2 Likes
Hi @brian,
After trying it out now, it works great!
I made this short demo 
- and using the horizontal/vertical restraint feature was a godsend. Thank you!
4 Likes
I’m sure J. Strauss II will be turn over in his grave! 
2 Likes
Perfectly straight movement. I can see how the constraint feature would make that faster!
1 Like
He certainly would, @SergeC ! Thanks for watching!! 
Yes indeed. It really made life much easier. Thank you for this feature!
I don’t want to be all “old man yells at clouds” here but is anyone else being annoyed by this icon interfering with regular clicking in the timeline? I was happy with the workaround but after getting the newer nightly with the original code I forgot I had the change and in the 5 minutes I tried to live with it, there was a 50% change of clicking on it by mistake.
I mean, doesn’t everyone have the filter panel always open thus making it highly redundant? And clicking it deselctes shift/ctrl selections (so it can show the filters for the current clip only). I also use double clicking a lot to move the playhead to the start of the clip and now I have to click around it.
I very much like the visual indication that the clip has a filter. But I think it should not interact with the mouse click. I mean, I can edit the qml file now and for every update, but just wanted to see if I’m in the minority here or something other people are not affected at all.
I think what you are talking about will be confusing because it is not in the published beta. He is referring to a Filters icon added to add Timeline clips that have a filter added–similar to what happens with track heads.
I was hesitant to add it for a lot of the same reasons. If click handling is turned off, it probably should be turned off as well for track heads. But then any change like that will get complaints, bug reports, and suggestions. Ditto if it is inconsistent (click works in some places and not in others). What do you think about that?
clicking it deselects shift/ctrl selections
That is a very strong point that can be argued is a UX bug.
True, I forgot this part.
If it is all or nothing I’d choose it to be present (with or without enabled/onClick behaviour) because I really think it adds value.
For the inconsistency part I do not mind it in this case, but I’m pretty sure it is because I got used to the buttons on the trackhead doing stuff while the timeline clips interacting is only for selecting and moving/trimming (yes, I also dislike the fade in/out bullets for small clips so I believe my hatred is consistent here 
).
Really the only issue is for people who use the smallest size for track heights, which I’ve been exclusively using for years. Oh and the selection thing, that’s not fun when it happens.
While it would be inconsistent if clicking does not work, I think it is worth pointing out that in the Output and Track header, the icon looks like a button. But on the clip, it is styled differently and looks more like a decoration on the name. So I can personally accept that the behavior is different since the look is different.
1 Like