Bug 800, selecting near clip boundaries

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug 800, selecting near clip boundaries

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.)

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



------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 800, selecting near clip boundaries

Gale
Administrator
On 29 June 2017 at 18:52, Paul Licameli <[hidden email]> wrote:

> 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?


> 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.
> As (3) but with more display changes for discoverability:
>
> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 800, selecting near clip boundaries

Paul Licameli


On Thu, Jun 29, 2017 at 7:00 PM, Gale Andrews <[hidden email]> wrote:
On 29 June 2017 at 18:52, Paul Licameli <[hidden email]> wrote:
> 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?

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.
 


> 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.
> As (3) but with more display changes for discoverability:
>
> 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

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

 

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel


------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 800, selecting near clip boundaries

Stevethefiddle
In reply to this post by Gale
On 30 June 2017 at 00:00, Gale Andrews <[hidden email]> wrote:

> On 29 June 2017 at 18:52, Paul Licameli <[hidden email]> wrote:
>> 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.


>
> And yet drag over the split line and Join from the Edit Menu still works?
>
>
>> 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.
>> As (3) but with more display changes for discoverability:
>>
>> 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

>
>
>
> Gale
>
> ------------------------------------------------------------------------------

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug 800, selecting near clip boundaries

Gale
Administrator
On 30 June 2017 at 00:34, Steve the Fiddle <[hidden email]> wrote:

> On 30 June 2017 at 00:00, Gale Andrews <[hidden email]> wrote:
>> On 29 June 2017 at 18:52, Paul Licameli <[hidden email]> wrote:
>>> 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.
>
>
>>
>> And yet drag over the split line and Join from the Edit Menu still works?
>>
>>
>>> 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.
>>> As (3) but with more display changes for discoverability:
>>>
>>> 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

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel
Loading...