Discussion:
[Audacity-devel] Bug 800, selecting near clip boundaries
Paul Licameli
2017-06-29 17:52:12 UTC
Permalink
This was occasion for argument over wording of a status message, when it
seems more is needed.

How seriously do we want to do something about this old "bugbear"?

If you try to click and drag starting at a boundary between clips, meaning
to select, you merge the clips which is not what you really want.

(Of some relevance is my recent commit
1c0af829030e4f0a294a15724167be88f46d6b56. This makes this click to join
unavailable in spectrogram view, because the boundaries are not drawn.)

I throw out some proposals, disregarding development difficulty for now.


1. Don't join the clip until button-up. If a drag begins before that,
select instead.
2. Implement TAB key cycling among hit-test candidates. (Just that, not
going the whole distance, of abolishing the Tools toolbar.)
3. Restrict click-to-join to only a part (which?) of the vertical extent
of the line. Make some cursor distinction from selection.
4. As (3) but with more display changes for discoverability:
1. Draw something like an X in a box or circle, as the restricted hit
target, and draw it always in non-spectrogram views.
2. As (1) but drawn only when the pointer is over the line, but then,
over any part of it.

The question also arises, what to do for cutlines. If we do version 3 for
boundaries, then similar ought to be done for cutlines, but then perhaps we
need to draw two thingies, one to delete, and another (like the east-west
cursor?) to expand.

PRL
Gale Andrews
2017-06-29 23:00:44 UTC
Permalink
Post by Paul Licameli
This was occasion for argument over wording of a status message, when it
seems more is needed.
How seriously do we want to do something about this old "bugbear"?
If you try to click and drag starting at a boundary between clips, meaning
to select, you merge the clips which is not what you really want.
(Of some relevance is my recent commit
1c0af829030e4f0a294a15724167be88f46d6b56. This makes this click to join
unavailable in spectrogram view, because the boundaries are not drawn.)
And yet drag over the split line and Join from the Edit Menu still works?
Post by Paul Licameli
I throw out some proposals, disregarding development difficulty for now.
Don't join the clip until button-up. If a drag begins before that, select
instead.
Implement TAB key cycling among hit-test candidates. (Just that, not going
the whole distance, of abolishing the Tools toolbar.)
Restrict click-to-join to only a part (which?) of the vertical extent of the
line. Make some cursor distinction from selection.
Draw something like an X in a box or circle, as the restricted hit target,
and draw it always in non-spectrogram views.
As (1) but drawn only when the pointer is over the line, but then, over any
part of it.
The question also arises, what to do for cutlines. If we do version 3 for
boundaries, then similar ought to be done for cutlines, but then perhaps we
need to draw two thingies, one to delete, and another (like the east-west
cursor?) to expand.
I considered selecting from cutlines but I really thought it made the feature
more complex for almost no benefit.



Gale
Paul Licameli
2017-06-29 23:28:45 UTC
Permalink
Post by Paul Licameli
Post by Paul Licameli
This was occasion for argument over wording of a status message, when it
seems more is needed.
How seriously do we want to do something about this old "bugbear"?
If you try to click and drag starting at a boundary between clips,
meaning
Post by Paul Licameli
to select, you merge the clips which is not what you really want.
(Of some relevance is my recent commit
1c0af829030e4f0a294a15724167be88f46d6b56. This makes this click to join
unavailable in spectrogram view, because the boundaries are not drawn.)
And yet drag over the split line and Join from the Edit Menu still works?
Yes, the clip boundary in spectrogram is still a snap-to location when
dragging the end of the selection, and yes, join still removes it.
Post by Paul Licameli
Post by Paul Licameli
I throw out some proposals, disregarding development difficulty for now.
Don't join the clip until button-up. If a drag begins before that,
select
Post by Paul Licameli
instead.
Implement TAB key cycling among hit-test candidates. (Just that, not
going
Post by Paul Licameli
the whole distance, of abolishing the Tools toolbar.)
Restrict click-to-join to only a part (which?) of the vertical extent of
the
Post by Paul Licameli
line. Make some cursor distinction from selection.
Draw something like an X in a box or circle, as the restricted hit
target,
Post by Paul Licameli
and draw it always in non-spectrogram views.
As (1) but drawn only when the pointer is over the line, but then, over
any
Post by Paul Licameli
part of it.
The question also arises, what to do for cutlines. If we do version 3
for
Post by Paul Licameli
boundaries, then similar ought to be done for cutlines, but then perhaps
we
Post by Paul Licameli
need to draw two thingies, one to delete, and another (like the east-west
cursor?) to expand.
I considered selecting from cutlines but I really thought it made the feature
more complex for almost no benefit.
Gale
I see my message crossed with James' independent and very simple solution.
I need to catch up in the other conversation. I am not sure that I like
the appearance, but I am not saying that with RM authority.

PRL
Post by Paul Licameli
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
audacity-devel mailing list
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Steve the Fiddle
2017-06-29 23:34:44 UTC
Permalink
Post by Gale Andrews
Post by Paul Licameli
This was occasion for argument over wording of a status message, when it
seems more is needed.
How seriously do we want to do something about this old "bugbear"?
If you try to click and drag starting at a boundary between clips, meaning
to select, you merge the clips which is not what you really want.
(Of some relevance is my recent commit
1c0af829030e4f0a294a15724167be88f46d6b56. This makes this click to join
unavailable in spectrogram view, because the boundaries are not drawn.)
In some cases splits can still be seen. For example, split a generated
tone or chirp.

Clicking on a split in Spectrogram view will "sometimes" merge the
clips and sometimes not.

I've never bothered exploring why or when as splitting and joining is
something that I would always do in waveform view. In spectrogram view
there is no way of knowing if the waveform is going to join up
smoothly or have a massive glitch at the join.
Post by Gale Andrews
And yet drag over the split line and Join from the Edit Menu still works?
Post by Paul Licameli
I throw out some proposals, disregarding development difficulty for now.
Don't join the clip until button-up. If a drag begins before that, select
instead.
Implement TAB key cycling among hit-test candidates. (Just that, not going
the whole distance, of abolishing the Tools toolbar.)
Restrict click-to-join to only a part (which?) of the vertical extent of the
line. Make some cursor distinction from selection.
Draw something like an X in a box or circle, as the restricted hit target,
and draw it always in non-spectrogram views.
As (1) but drawn only when the pointer is over the line, but then, over any
part of it.
The question also arises, what to do for cutlines. If we do version 3 for
boundaries, then similar ought to be done for cutlines, but then perhaps we
need to draw two thingies, one to delete, and another (like the east-west
cursor?) to expand.
I considered selecting from cutlines but I really thought it made the feature
more complex for almost no benefit.
Not sure how or why the benefit is different from split lines.

Steve
Post by Gale Andrews
Gale
------------------------------------------------------------------------------
Gale Andrews
2017-06-30 00:22:20 UTC
Permalink
Post by Steve the Fiddle
Post by Gale Andrews
Post by Paul Licameli
This was occasion for argument over wording of a status message, when it
seems more is needed.
How seriously do we want to do something about this old "bugbear"?
If you try to click and drag starting at a boundary between clips, meaning
to select, you merge the clips which is not what you really want.
(Of some relevance is my recent commit
1c0af829030e4f0a294a15724167be88f46d6b56. This makes this click to join
unavailable in spectrogram view, because the boundaries are not drawn.)
In some cases splits can still be seen. For example, split a generated
tone or chirp.
Clicking on a split in Spectrogram view will "sometimes" merge the
clips and sometimes not.
I've never bothered exploring why or when as splitting and joining is
something that I would always do in waveform view. In spectrogram view
there is no way of knowing if the waveform is going to join up
smoothly or have a massive glitch at the join.
Post by Gale Andrews
And yet drag over the split line and Join from the Edit Menu still works?
Post by Paul Licameli
I throw out some proposals, disregarding development difficulty for now.
Don't join the clip until button-up. If a drag begins before that, select
instead.
Implement TAB key cycling among hit-test candidates. (Just that, not going
the whole distance, of abolishing the Tools toolbar.)
Restrict click-to-join to only a part (which?) of the vertical extent of the
line. Make some cursor distinction from selection.
Draw something like an X in a box or circle, as the restricted hit target,
and draw it always in non-spectrogram views.
As (1) but drawn only when the pointer is over the line, but then, over any
part of it.
The question also arises, what to do for cutlines. If we do version 3 for
boundaries, then similar ought to be done for cutlines, but then perhaps we
need to draw two thingies, one to delete, and another (like the east-west
cursor?) to expand.
I considered selecting from cutlines but I really thought it made the feature
more complex for almost no benefit.
Not sure how or why the benefit is different from split lines.
Split lines are the popularly requested feature we don't have
("permanent markers on the waveform", but not labels).


Gale

Loading...