After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 594389 - move playhead on click - better splitting metaphor
move playhead on click - better splitting metaphor
Status: RESOLVED FIXED
Product: pitivi
Classification: Other
Component: User interface
Git
Other Linux
: Normal enhancement
: 0.13.4
Assigned To: Pitivi maintainers
Pitivi maintainers
: 609518 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-09-07 16:32 UTC by Jean-François Fortin Tam
Modified: 2010-02-10 14:11 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2009-09-07 16:32:05 UTC
Ed said he would be interested in implementing/re-committing the "move playhead on click anywhere in the timeline" feature (somewhere in Emdash's branch) once it is fully integrated/polished and that it is cohesive with the new clip splitting metaphor.

For a demonstration of such an existing, fully-cohesive implementation with half-naked japanese men singing on a stage:

http://jeff.ecchi.ca/public/fast%20splitting%20-%20edited.ogv

Citation:
--------------------------------------
<bilboed> :)
 ok, I'm sold
<nekohayo> hahaha
<bilboed> but ONLY if it feels as intuitive as your screencast
[...]
<nekohayo> that thing only makes sense when it's "all integrated"
<bilboed> I meant the clicking :)
<nekohayo> nice :)
<bilboed> and yes, if everything ties together (clicking/zooming/cutting/triming/selecting/...) it makes total sense
<nekohayo> that's why I felt a bit surprised when emdash's commits a few weeks ago were reverted, I thought "the fools! how could they not grasp the inherent beauty of that thing?!" and then I realized that it was not entirely implemented to be coherent
<bilboed> as I said before it was reverted because "this out-of-context single commit is creating more problems than creating any"
<nekohayo> now, with all this, I'm not saying the "razor" tool should go away though, both can coexist nicely I assume
 sure
 oh
<bilboed> the razor would just become a 'click' button (and no longer a toggle one)
Comment 1 Jean-François Fortin Tam 2009-11-21 01:34:24 UTC
As requested by emdash, here is an extensive analysis of the HCI involved in this, to clarify all the little details that need to be implemented for this to make sense.


BEHAVIOR OF THE PLAYHEAD IN VARIOUS MOUSE/KEYBOARD INTERACTION SCENARIOS
- Simple click on an empty space on the timeline: playhead moves
- Simple click on a clip on the timeline: playhead moves, clip is selected, other clips are deselected
- Simple click on a clip when holding shift or control (or any modifier): click is added or removed to the selection, playhead does not move
- Simple click on the ruler: playhead moves
- Click and drag on the ruler: playhead scrubs
- Click and drag on an empty space of the timeline: marquee selection (aka rectangle box)
- Click and drag on an empty space of the timeline while holding shift: make a region selection (and the playhead scrubs by following the "end" point of the selection, where the mouse cursor is)
- Click and drag on a clip: clip moves, playhead does not move (same thing for multiple clips)
- Click and drag on clip trimming handles, ripple or roll edits, etc (anything that uses a drag): playhead does not move
- Manipulate internal clip objects (such as keyframes, curve segments, buttons if we have them one day, etc.): playhead does not move
- Right click, middle click: playhead does not move. This should be preserved for other features (such as popup menus).

Basically, to summarize my logic: playhead moves only when not using modifier keys and when not in a mouse drag operation on a clip. This tightly integrated workflow allows:
- still being able to do quick clip selection (ie: preserving the "natural" way of handling selections)
- easy scrubbing
- very accurate editing (you can position the mouse cursor directly over waveforms, instead of over the ruler)
- easy "repositioning" of your "accurate edit" when you zoomed further in "around" the playhead (you just need to click again to redefine where the playhead should be)
- "warping" (moving very efficiently) along the timeline by clicking, zooming, clicking, etc.
- non-modal splitting

Regarding non-modal splitting, there question that comes to mind is "does it only split selected clips?", to which the answer is, "yes and no"! The trick is that if some clips are selected, the split applies only to the selected ones, but if no clips are selected, the split applies across the entire timeline height. This is an important reason why clicking a clip (without modifier keys) moves the playhead AND selects that only clip; thus, by default, splits are applied to only one clip, unless the user clearly chooses to apply it to everything (by clicking a blank space to move the playhead and, at the same time, deselect all clips).

This is why it only makes sense when it's all tightly integrated together as a coherent workflow. Once you experience this, you'll be delighted at its inherent beauty :)
Comment 2 Jean-François Fortin Tam 2010-02-10 14:11:54 UTC
*** Bug 609518 has been marked as a duplicate of this bug. ***