Created attachment 133809 [details]
demonstration of the problem

I am not so sure I consider this a bug. It's difficult to ignore the clip's original start position without also ignoring edges that the clip might have been originally adjacent to. In other words, this behavior is only really incorrect when the clip is floating by itself in space, and even then I still think it is useful to be able to put a clip back exactly where you found it. We still don't have undo/redo.

I think I would rather add the ability to disable edge snapping temporarily during the few occasions when it isn't needed (by holding down a modifier key, maybe shift). Moreover, once we add ripple/roll editing, you'd want to use that instead of dragging for making fine adjustments between clips anyways. For ripple/roll editing, edge snapping would not need to be applied.

I'm slightly concerned that edge snapping might create the perception of sluggishness because movement of clips is delayed until the mouse has moved a certain number of pixels. To help alleviate this, it might be a good idea, as you suggested earlier, to provide some additional feedback so that the user is aware of when and where edge snapping is being applied, probably by bringing up a vertical line across the timeline. I have noticed that even I am not always aware which side of the  of the clip is "snagging" on an edge. In addition, there's an optical illusion which makes staggered clips appear not to be aligned to each other when separated by a large enough vertical gap, and this would help to correct that.

> this behavior is only really
> incorrect when the clip is floating by itself in space,

Precisely. It wouldn't be problematic if the clip was stuck between two other clips, but when it's alone on its layer, I expect to be able to fine-tune it to match the music, for example. And adjusting sound effects synchronization this way would be terrible.

> and even then I still
> think it is useful to be able to put a clip back exactly where you found it.
> We still don't have undo/redo.

Then the correct behavior for this use case is to implement undo/redo eventually. Personnally, even without undo/redo, I prefer being able to precisely position "lone" clips; I usually don't use undo/redo in cases I do a positioning mistake, I just reposition in a gradually more accurate way; that's what disabling snapping for this use case provides.

> I'm slightly concerned that edge snapping might create the perception of
> sluggishness because movement of clips is delayed until the mouse has moved a
> certain number of pixels.

I agree, this is part of the frustration of a lone clip snapping to itself; it takes a lot of "force" to move it, especially if you set snapping to 10 pixels (5 pixels is too small a target for me in regular use at 1920x1200).

> To help alleviate this, [...]
> provide some additional feedback [...]
> by bringing up a vertical line across the timeline.

Makes sense to me. I've seen Vegas do exactly that (but the clips don't snap to themselves, only to adjacent clips on the same layer ;).

Retitling for clarity. Note that this bug can now be reconsidered; as undo/redo has been implemented, there probably is nothing blocking this.

The vertical line is a separate thing, bug #610217

Clips don't snap to themselves (their original position) in the new Pitivi timeline implementation now.