Re: [Audacity-quality] Should snapping a region to a label delete the label as well as the region?

[Al D. <bus...@gm...>]

On Friday, September 17, 2010 01:59:36 Gale Andrews wrote:
> Sorry it's taken a few days to get back to you, Al. See below.
> 

It's OK -- I would have taken just as long to respond, I didn't have 
much time this past week.

> | From Al Dimond <bus...@gm...>
> | Sat, 11 Sep 2010 22:31:17 -0700
> | Subject: [Audacity-quality] Should snapping a region to a label
> | delete the label as well as the region?
> | 
> > On Saturday, September 11, 2010 16:15:57 Gale Andrews wrote:
> > > | From Al Dimond <bus...@gm...>
> > > | Sat, 11 Sep 2010 12:20:43 -0700
> > > | Subject: [Audacity-quality] Should snapping a region to a
> > > | label delete the label as well as the region?
> > > | 
> > > > On Wednesday, September 08, 2010 23:44:09 Al Dimond wrote:
> > > > > I've been experimenting with this. It's not ready to check
> > > > > in yet -- one problem is that when you Select All in a
> > > > > label track and delete, labels can remain. Generally it's
> > > > > impossible to delete point labels at time 0.
> > > > > 
> > > > > We could have label tracks report their beginning/end times
> > > > > slightly beyond what they are, to affect how Select All
> > > > > works... but I'm not sure we should mess with reporting
> > > > > track length. We could special-case it and include point
> > > > > labels at 0 and at track-end time when the selection
> > > > > borders them. That's the best idea I have right now.
> > > > 
> > > > I currently have this sitting in my tree, working as
> > > > specified above: point labels bordering the selection aren't
> > > > included in it unless they're at time 0 or the very end of
> > > > the track. Does anyone object to that behavior? I'll check
> > > > it in in a few days if there's no comment.
> > > 
> > > Thanks, Al. Is there the same problem with a final point label
> > > that's before the end of the track/project - it won't delete
> > > after clicking in the label track to select all the labels?
> > 
> > What do you mean be "final point label that's before the end of
> > the track/project"?
> 
> 1 Create a 30s tone
> 2 Click at 5s, CTRL + B
> 3 Click at 25s, CTRL + B
> 
> The label at 25s is a "final point label before the end of the
> track/project." So I was figuring that being the last label, it
> needs the same decisions as a label that actually is at the end of
> the track.
> 

It's a final point label before the end of the project, but not before 
the end of the track. It's at the end of the track, so the same 
considerations apply.

> > What do you mean by "clicking in the label track to select all
> > the labels"? I'm not aware of any such functionality.
> 
> You'll have to turn sync-lock off to see it now. With sync-lock
> off, you can also see it if you double-click in the label track. I
> don't like it, and wouldn't mind losing that when sync-lock is off
> too.
> 

So you mean double-clicking. Double-click in any track does the same 
thing as Edit->Select All, so yes, I was including this in that 
discussion.

> Rather than double-clicking in the label track selecting all of it,
> I'd prefer longer term that it selected between labels (unless we
> find a better way to do that). See:
> http://wiki.audacityteam.org/wiki/Proposal_Label_Enhancements#Multi
> -select
> 

OK. I guess that discussion should be separate (it's very distant, 
code-wise, and it seems like a big behavior decision).

> > > I'm not sure why the label at zero won't delete when you select
> > > all the labels because the selection must be transgressing it.
> > > I don't think the transgression rule should depend on the
> > > selection starting from before the label edge otherwise you
> > > won't be able to select from a point label part way over the
> > > label name and delete it?
> > 
> > What does the label name have to do with anything?
> 
> Selecting over the label name is just a specific case of having to
> select (rightwards) past a point label in order to delete it. I
> didn't mean it to have any significance in itself.
> 
> However people do delete point labels by clicking in them and
> dragging rightwards from there, so I wanted to be sure that would
> still work.
> 
> > > In other words the deletion trigger is if the selection
> > > extends rightwards from the label edge irrespective where it
> > > starts from.
> > 
> > So you think that if you select "up to" a point label from the
> > left it should not be included in the selection, but if you
> > select "up to" a point label from the right, it should be
> > included in the selection? I wrote it so that selecting "up to"
> > a point label never included it in the selection from either
> > side.
> 
> No, I just wasn't considering selecting from the right. I think you
> have it correct now. So if selecting from the right, you have to
> transgress the point label to include it in the selection, just as
> if you select it from the left.
> 
> My suggestion therefore was that if the selection transgresses the
> edge of the point label in the direction of drag, the label is
> included in the selection, but that should be true even if the
> selection starts from the label point.
> 
> > > Ideally I would still like to select from somewhere before the
> > > last label and snap to the last label, but not delete it.
> > > Could there be a rule that it's OK to delete the last point
> > > label when a selection doesn't transgress it if the selection
> > > starts from the first label?
> > 
> > ... I don't think it's totally unreasonable that selecting "up
> > to" a point label from the left should act different from
> > selecting "up to" a point label from the right. If we're going
> > to do that, we might as well not special-case end-of-track
> > labels at all -- if Select All misses them it's not that big a
> > deal -- it's easy to make the selection include them. The really
> > big problem was having point labels at time 0 being very
> > difficult to delete (without moving them).
> 
> If you're happier that you always have to transgress the point
> label in the direction of drag to include it in the selection, I'm
> happy too. If we make clicking on the label track always select up
> to the end of an audio track above (irrespective of sync-lock
> state), then that will delete final point labels that are not at
> the end of the track. A point label at the end of the track will I
> presume then get moved to time 0.
> 
> But I think making an exception so that the last label is included
> in the selection when you select (rightwards) up to it from zero
> may be more useful.
> 

At the time the labels are being, i.e., cleared, we don't know which 
direction the selection was dragged in. In fact, there are many ways 
to set or modify the selection other than dragging, and we don't know 
about any of that at the time the labels are being cleared. And while 
selection isn't taking place we don't keep track of which labels are 
becoming selected/unselected. We select some audio, it's just two 
points in time, and we figure out what that means when we use it for an 
operation.

I suppose we could think about the selection having "inclusive" and 
"exclusive" endpoints -- they either include or exclude a point label 
at that time exactly. The ends of the selection are always inclusive 
unless dragged to, in which case they're exclusive. I think that would 
provide the behavior you're looking for, in theory. The problems I see 
with this are:

1. It's tricky to get right. We'd have to consider edge inclusiveness 
*every time* we changed the selection, and some of these cases could 
be ambiguous. It would create lots of subtle bugs, behavior changes, 
and behavior arguments, and those seems like the things we should be 
trying to avoid right now.

2. To give users half a chance we'd need to show them edge 
inclusiveness (in label tracks, where it applies). To give them a full 
chance we'd need a way for them to control it (to make an inclusive 
edge exclusive and vice-versa). Again, this seems like bad timing -- 
we need to be fixing bugs, not creating new surfaces for them to land 
on.

So I'm down on variable edge-inclusiveness.


I'm starting to think that it's a pretty significant problem for Select 
All not to "capture" all labels in a track. And I think the case where 
the last point label in a track isn't at the end of the project is 
problematic for special-cases. The clearest way forward is to make all 
selection edges inclusive.

I'll still have some changes to check in, centralizing label track 
edge detection and fixing some copy/paste inconsistencies. If we want 
to continue this discussion that's fine -- the code will be in place 
such that changing behavior won't be hard.

 - Al

> 
> 
> 
> 
> Gale
> 
> 
> 
> 
> -------------------------------------------------------------------
> ----------- Start uncovering the many advantages of virtual
> appliances and start using them to simplify application deployment
> and accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Audacity-quality mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality