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 625694 - Show trimming handles in the lower half of the clip only
Show trimming handles in the lower half of the clip only
Status: RESOLVED WONTFIX
Product: pitivi
Classification: Other
Component: Timeline
Git
Other Linux
: Normal normal
: 0.91
Assigned To: Pitivi maintainers
Pitivi maintainers
Depends on:
Blocks:
 
 
Reported: 2010-07-30 22:31 UTC by DELETED
Modified: 2013-10-04 20:48 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
mock-up (13.12 KB, image/png)
2010-07-30 22:31 UTC, DELETED
  Details
Testcase (2.17 KB, patch)
2010-09-06 13:20 UTC, DELETED
none Details | Review

Description DELETED 2010-07-30 22:31:37 UTC
Created attachment 166863 [details]
mock-up

By having only the lower half of the current trimbars, it would be possible to easily move clips that appear to be 'nothing but trimbars' at the current zoom level, by clicking on the upper half. Currently you have to zoom in far enough so that you can click in the space between the trimbars in order to move tiny clips.

I took the idea from Lombard, where it's not intuitive at all though, because it doesn't show trimbars at all. The user has to KNOW that he has to move the pointer to the lower half of the clip edge in order to trim it.

See attached mock-up.
Comment 1 DELETED 2010-09-06 13:20:47 UTC
Created attachment 169572 [details] [review]
Testcase

When playing around with it, you'll notice the big drawback that, if keyframe marks at the clip edges are in the lower half, too, you have to be very precise to either select the keyframe mark or the trim handle.

So, this needs some thoughts still.
Comment 2 Jean-François Fortin Tam 2010-09-07 01:50:29 UTC
I remember emdash having done various experiments (as git branches) for trimming handles, also with rounded clip corners, but they all seemed to have drawbacks of some sorts (or we sat on those and they got forgotten).

IMHO, I think losing the full height of the trimbars seems like a non-optimal solution (Fitt's law and all that).

Here's an idea though: why not simply "not show" the trimming handles if the clip is not "long" enough? 
Basically, hide them (even when the mouse is over the clip) when the clip's width (on the timeline canvas) is less than 4 times the width of a trimming handle (meaning there is insufficient space to properly trim anyway). Or we could hardcode an arbitrary width (ex: 30 pixels).

If the user really wants to trim those tiny clips, then he'll zoom in (which is what is happening right now anyway).

This way, we get the best of both worlds.
Comment 3 DELETED 2010-09-09 01:58:12 UTC
(In reply to comment #2)
> I remember emdash having done various experiments (as git branches) for
> trimming handles, also with rounded clip corners, but they all seemed to have
> drawbacks of some sorts (or we sat on those and they got forgotten).
> 
> IMHO, I think losing the full height of the trimbars seems like a non-optimal
> solution (Fitt's law and all that).
OK, I agree, I admit that I don't like the look of them neither!

> 
> Here's an idea though: why not simply "not show" the trimming handles if the
> clip is not "long" enough? 
> Basically, hide them (even when the mouse is over the clip) when the clip's
> width (on the timeline canvas) is less than 4 times the width of a trimming
> handle (meaning there is insufficient space to properly trim anyway). Or we
> could hardcode an arbitrary width (ex: 30 pixels).
> 
> If the user really wants to trim those tiny clips, then he'll zoom in (which is
> what is happening right now anyway).
> 
> This way, we get the best of both worlds.
That sounded great to me (because it's simple) at first, but in fact it is not. Lets assume the user has a project open with many clips that may or may not be wide enough to show trimbars when the user hovers the pointer over them. However, the user will have no idea at which zoom level the trimbars will show up. He'd have to hover his mouse over the clip he wants to trim while he's zooming (and the clip would even jump away unless the playhead is on it ...) . This is VERY unintuitive, because that would hide information (= is this clip wide enough so that the trimbars will appear if I hover over it?) from the user, and he'd have to take action (move the mouse to the clip in question) to get the answer.

One could avoid that problem if by showing the trimbars ALL the time (even if the pointer is not hovering over them) for clips that are wide enough, and not show them for clips that are too small. But this would look very ugly and confusing, IMHO.
Comment 4 Brandon Lewis 2010-11-23 12:47:51 UTC
> One could avoid that problem if by showing the trimbars ALL the time (even if
> the pointer is not hovering over them) for clips that are wide enough, and not
> show them for clips that are too small. But this would look very ugly and
> confusing, IMHO.

This is why we only show the trim bars on mouse-over. We  used to show them all the time, and the result was visually very cluttered.

It's a deceptively tricky problem. For example, I tried moving the trim handles outside the clip, so that even for very small clips the handles were still operable. But this doesn't work either, beacuse clips frequently appear back-to-back. When the handles are outside the clip, deciding which clip they belong to becomes difficult.
Comment 5 Jean-François Fortin Tam 2013-10-04 20:48:14 UTC
So, this is a can of worms with many many many repercussions in terms of user experience. Given that the current behavior works for 99% of cases (just need to zoom in to move stuff if the clip is not wide enough), that there is no clear course of action, and that nobody provided an implementation/patch for this in three years, I'll close this (sorry!)