Audacity Clipboard WAS Re: Large commit coming -- VS project will need updating

[Gale (Audacity Team)]

| From Al Dimond <[hidden email]>
| Tue, 3 Nov 2009 12:34:53 -0600
| Subject: [Audacity-devel] Large commit coming -- VS project will need updating

> On Tuesday 03 November 2009 04:00:45 Gale Andrews wrote:
> > Hi Al, some concerns over the new clipboard behaviour and
> > Labeled Regions items especially pasting...
> >
> > | From Bill Wharrie <[hidden email]>
> > | Mon, 2 Nov 2009 11:46:53 -0500
> > | Subject: [Audacity-devel] Large commit coming -- VS project will
> > | need updating
> > |
> > > On 31-Oct-09, at 11:20 AM, Al Dimond wrote:
> > >  - When you copy tracks to the clipboard, the system clipboard is
> > > set to represent the labels selected.  Any label fully overlapped
> > > by the selection is added, with labels separated by tabs and
> > > label tracks separated by newlines.
> >
> > Isn't the Audacity clipboard able to capture the label text as well
> >  as the audio, then? This is quite a liability for people who use
> >  clipboard managers which store every clip.
> >
>
> As it stands Audacity's clipboard, where copied tracks are stored, is
> completely separate from the system clipboard.  We could add a
> separate Audacity text clipboard but that wouldn't help us get the
> desired behavior.
>
>  - If you've just copied something from a text document, we want a new
> label created with that text.

Hi Al,

For that, where we already have a label, we have right-click in the
label > Paste. Before this change, I believe those right-click functions
were the only case where Audacity used the system clipboard for labels.

To my mind, in the case where you want to click in empty space in the
label track and create a new label from the system clipboard, there
should be an analogous right-click item.


>  - If you've just copied part of a label track from Audacity we want
> that new part copied in.
>
> What we want is to honor the most recent thing copied to the
> clipboard, whether it was Audacity data or text.

See above.


> Without writing to the system clipboard we can't do that (some platforms'
> clipboards have timestamps, and some platforms let you listen for clipboard
> events -- if either approach was supported by wxWidgets we could use those
> instead, but it doesn't sound like either is universal enough to be
> usable by wx).  We have to write to the system clipboard on a copy and
> then, on a paste, check whether some other program overwrote what we
> wrote there.  Even if there isn't any label text to write.

Strongly disagree, unless this is the only way to capture label (with
text) and audio combined. If it is, fair enough.  I can see no
justification for capturing "audio data only" to the system clipboard  
which destroys the user's clipboard data (with a basic Windows
clipboard).

> One problem with this is that it's impossible to distinguish
> Audacity's text from a user copying the exact same text from another
> program.  There is no perfect way around this using this scheme...
> maybe we could prefix the string we copy with "Audacity:".  The problem
> would still exist, but as users would be unlikely to copy that prefix
> with the intention of pasting it into a new label, it would be less
> likely to occur in practice.
>
> > And I note it's using the system clipboard even for audio only, so
> > knocking current text off the clipboard. Supposing I didn't have a
> > clipboard manager and that was a clip I was just about to paste
> >  into a document? Would I have expected Audacity to erase that clip
> >  permanently when copying audio?
> >
> Most programs operate on the system clipboard when you use Edit->Copy.  
> Some programs (i.e. vim) have separate cut buffers, but you explicitly
> control when you use them.  I wouldn't expect Audacity to act any
> differently.

Vim is a text editor, so not fully relevant. Users will expect a text editor
to use the system clipboard, unless it has its own specialist clipboard.  
I'll admit I don't have many "other" audio editors on my computer, but
Goldwave and CoolEditPro both use their own internal clipboard for
audio data, as Audacity always did before today (CEP has options to use
the Windows clipboard).

I believe your change (at least for "audio data only") will not be
universally welcomed and will lead to "bug reports", especially for
users switching from 1.2. So I'd like to be convinced please, if your
scheme is necessary for capturing "audio-with-label", why it is
necessary for "audio-only".  


Thanks



Gale  
 


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Tuesday 03 November 2009 14:12:04 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Tue, 3 Nov 2009 12:34:53 -0600
> | Subject: [Audacity-devel] Large commit coming -- VS project will
> | need updating
> |
> > On Tuesday 03 November 2009 04:00:45 Gale Andrews wrote:
> > > Hi Al, some concerns over the new clipboard behaviour and
> > > Labeled Regions items especially pasting...
> > >
> > > | From Bill Wharrie <[hidden email]>
> > > | Mon, 2 Nov 2009 11:46:53 -0500
> > > | Subject: [Audacity-devel] Large commit coming -- VS project
> > > | will need updating
> > > |
> > > > On 31-Oct-09, at 11:20 AM, Al Dimond wrote:
> > > >  - When you copy tracks to the clipboard, the system
> > > > clipboard is set to represent the labels selected.  Any label
> > > > fully overlapped by the selection is added, with labels
> > > > separated by tabs and label tracks separated by newlines.
> > >
> > > Isn't the Audacity clipboard able to capture the label text as
> > > well as the audio, then? This is quite a liability for people
> > > who use clipboard managers which store every clip.
> >
> > As it stands Audacity's clipboard, where copied tracks are
> > stored, is completely separate from the system clipboard.  We
> > could add a separate Audacity text clipboard but that wouldn't
> > help us get the desired behavior.
> >
> >  - If you've just copied something from a text document, we want
> > a new label created with that text.
>
> Hi Al,
>
> For that, where we already have a label, we have right-click in the
> label > Paste. Before this change, I believe those right-click
>  functions were the only case where Audacity used the system
>  clipboard for labels.
>

Before this change Audacity only ever wrote to the system clipboard
when you specifically copied text from a label (which can be done
through a context menu while editing a label's text, or by Edit->Copy
while editing a label's text).

> To my mind, in the case where you want to click in empty space in
>  the label track and create a new label from the system clipboard,
>  there should be an analogous right-click item.
>

I have no problem with only reading from the system clipboard while
editing label text, or with a separate menu command like "Paste text
into new label" (if you're not into the whole brevity thing).  Maybe
even a context menu, although we don't appear to use context menus
outside of text editing currently.

> >  - If you've just copied part of a label track from Audacity we
> > want that new part copied in.
> >
> > What we want is to honor the most recent thing copied to the
> > clipboard, whether it was Audacity data or text.
>
> See above.
>
> > Without writing to the system clipboard we can't do that (some
> > platforms' clipboards have timestamps, and some platforms let you
> > listen for clipboard events -- if either approach was supported
> > by wxWidgets we could use those instead, but it doesn't sound
> > like either is universal enough to be usable by wx).  We have to
> > write to the system clipboard on a copy and then, on a paste,
> > check whether some other program overwrote what we wrote there.
> > Even if there isn't any label text to write.
>
> Strongly disagree, unless this is the only way to capture label
>  (with text) and audio combined. If it is, fair enough.  I can see
>  no justification for capturing "audio data only" to the system
>  clipboard which destroys the user's clipboard data (with a basic
>  Windows clipboard).
>
> > One problem with this is that it's impossible to distinguish
> > Audacity's text from a user copying the exact same text from
> > another program.  There is no perfect way around this using this
> > scheme... maybe we could prefix the string we copy with
> > "Audacity:".  The problem would still exist, but as users would
> > be unlikely to copy that prefix with the intention of pasting it
> > into a new label, it would be less likely to occur in practice.
> >
> > > And I note it's using the system clipboard even for audio only,
> > > so knocking current text off the clipboard. Supposing I didn't
> > > have a clipboard manager and that was a clip I was just about
> > > to paste into a document? Would I have expected Audacity to
> > > erase that clip permanently when copying audio?
> >
> > Most programs operate on the system clipboard when you use
> > Edit->Copy. Some programs (i.e. vim) have separate cut buffers,
> > but you explicitly control when you use them.  I wouldn't expect
> > Audacity to act any differently.
>
> Vim is a text editor, so not fully relevant. Users will expect a
>  text editor to use the system clipboard, unless it has its own
>  specialist clipboard. I'll admit I don't have many "other" audio
>  editors on my computer, but Goldwave and CoolEditPro both use
>  their own internal clipboard for audio data, as Audacity always
>  did before today (CEP has options to use the Windows clipboard).
>
> I believe your change (at least for "audio data only") will not be
> universally welcomed and will lead to "bug reports", especially for
> users switching from 1.2. So I'd like to be convinced please, if
>  your scheme is necessary for capturing "audio-with-label", why it
>  is necessary for "audio-only".
>

After the change, the way we decide whether to try a paste from the
system clipboard or to go straight to the internal clipboard is:

1. Run the same function that Copy uses to generate clipboard text on
Audacity's internal clipboard
2. Compare the resulting text to the contents of the system clipboard.

If we don't write an empty string to the system clipboard during the
copy, then when we paste, we don't know whether the text on the system
clipboard was put there before or after us.

The other scheme I thought of involved saving the clipboard text in
another static variable at copy-time, and see if it's changed at
paste-time.  But I thought it might be very common that a user could
have some text on the clipboard, then copy some audio in Audacity,
paste that audio somewhere, then copy the same text as before over
again, expecting to be able to paste it into a new label.  Under that
scheme, the second copy would be invisible.  Under the scheme I used,
the only invisible copies are ones that have the same text as
Audacity's generated clipboard text.  It's still possible, but less
likely.

I think it would be great to rip this out, because it's sort of ugly,
and it's always possible to game it.  We'd just have to agree that
Edit->Paste should only check the system clipboard during label edit,
and possibly create a new menu command like "Paste text into new
label" (not that it's very hard to go Ctrl-B Ctrl-V).  That would mean
a change in behavior for anyone that's used to copying something from
Notepad, clicking in a label track, hitting Ctrl-V, and getting a new
label with system clipboard text.  I don't really like that behavior
all that much, but since it existed and was definitely intended as a
feature I tried to preserve it where it made sense.

>
> Thanks
>
>
>
> Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

"Al Dimond" wrote
> I thought it might be very common that a user could
> [[A]] have some text on the clipboard, then copy some audio in Audacity,
> paste that audio somewhere, then copy the same text as before over
> again, expecting to be able to paste it into a new label.  Under that
> scheme, the second copy would be invisible.  Under the scheme I used,
> the only invisible copies are ones that have the same text as
> Audacity's generated clipboard text.  It's still possible, but less
> likely.

Exactly, it's a possible flaw.


> I think it would be great to rip this out, because it's sort of ugly,
> and it's always possible to game it.  We'd just have to agree that
> Edit->Paste should only check the system clipboard during label edit,
> and possibly create a new menu command like "Paste text into new
> label" (not that it's very hard to go Ctrl-B Ctrl-V).  That would mean
> a change in behavior for anyone that's used to [[B]] copying something from
> Notepad, clicking in a label track, hitting Ctrl-V, and getting a new
> label with system clipboard text.  I don't really like that behavior
> all that much, but since it existed and was definitely intended as a
> feature I tried to preserve it where it made sense.

Hi Al,

I've only ever seen good comments about the Audacity clipboard (especially
it doesn't mess with the system clipboard when holding audio data, and
also "click in label track and type" (or "paste the system clipboard"). The
bad press we got was the previous mess copying labels-with-audio and
not being able to do it, or getting system text in the label.

If we rip out what we have now, we can still do [[A]] can't we (you mean
they already have labelled audio with system text in it, and copy
audio-with-label)? Plus, in the also common case where user has some
system text already, copies un-labelled audio, pastes it and then labels it,
they don't have that system text erased by copying the audio as they do
now.

I believe checking system clipboard only when doing label edits is much the
best - it's what we always did.

I do think it's important we can still select over a label with its own text, then
copy and paste it with its own text. Can we still do that if we change what we
have now? Before the current change, you could actually do that, and not lose
the system clipboard, but by clicking in the audio track before paste. That was
unintuitive, but it also still let you paste the (different) system text by clicking
in the label track before paste. We don't have that possibility of access to
different clipboards now.

If (previous behaviour) people can find the right-click to paste system text into
a pre-existing label while the Audacity clipboard holds some other text, then I
don't think it's unreasonable when they want [[B]] to right-click at a point in the
label track to paste that other text (or some menu option different from "Paste").
My feedback was that people like the idea of the system and Audacity clipboard
having different contents. I'm not keen to throw that away, or keen to have
the system clipboard wiped whenever we copy. I'm interested in other views/
use cases though.




Gale



On Tuesday 03 November 2009 14:12:04 Gale Andrews wrote:
> | From Al Dimond <[e-mail]>
> | Tue, 3 Nov 2009 12:34:53 -0600
> | Subject: [Audacity-devel] Large commit coming -- VS project will
> | need updating
> |
> > On Tuesday 03 November 2009 04:00:45 Gale Andrews wrote:
> > > Hi Al, some concerns over the new clipboard behaviour and
> > > Labeled Regions items especially pasting...
> > >
> > > | From Bill Wharrie <[e-mail]>
> > > | Mon, 2 Nov 2009 11:46:53 -0500
> > > | Subject: [Audacity-devel] Large commit coming -- VS project
> > > | will need updating
> > > |
> > > > On 31-Oct-09, at 11:20 AM, Al Dimond wrote:
> > > >  - When you copy tracks to the clipboard, the system
> > > > clipboard is set to represent the labels selected.  Any label
> > > > fully overlapped by the selection is added, with labels
> > > > separated by tabs and label tracks separated by newlines.
> > >
> > > Isn't the Audacity clipboard able to capture the label text as
> > > well as the audio, then? This is quite a liability for people
> > > who use clipboard managers which store every clip.
> >
> > As it stands Audacity's clipboard, where copied tracks are
> > stored, is completely separate from the system clipboard.  We
> > could add a separate Audacity text clipboard but that wouldn't
> > help us get the desired behavior.
> >
> >  - If you've just copied something from a text document, we want
> > a new label created with that text.
>
> Hi Al,
>
> For that, where we already have a label, we have right-click in the
> label > Paste. Before this change, I believe those right-click
>  functions were the only case where Audacity used the system
>  clipboard for labels.
>

Before this change Audacity only ever wrote to the system clipboard
when you specifically copied text from a label (which can be done
through a context menu while editing a label's text, or by Edit->Copy
while editing a label's text).

> To my mind, in the case where you want to click in empty space in
>  the label track and create a new label from the system clipboard,
>  there should be an analogous right-click item.
>

I have no problem with only reading from the system clipboard while
editing label text, or with a separate menu command like "Paste text
into new label" (if you're not into the whole brevity thing).  Maybe
even a context menu, although we don't appear to use context menus
outside of text editing currently.

> >  - If you've just copied part of a label track from Audacity we
> > want that new part copied in.
> >
> > What we want is to honor the most recent thing copied to the
> > clipboard, whether it was Audacity data or text.
>
> See above.
>
> > Without writing to the system clipboard we can't do that (some
> > platforms' clipboards have timestamps, and some platforms let you
> > listen for clipboard events -- if either approach was supported
> > by wxWidgets we could use those instead, but it doesn't sound
> > like either is universal enough to be usable by wx).  We have to
> > write to the system clipboard on a copy and then, on a paste,
> > check whether some other program overwrote what we wrote there.
> > Even if there isn't any label text to write.
>
> Strongly disagree, unless this is the only way to capture label
>  (with text) and audio combined. If it is, fair enough.  I can see
>  no justification for capturing "audio data only" to the system
>  clipboard which destroys the user's clipboard data (with a basic
>  Windows clipboard).
>
> > One problem with this is that it's impossible to distinguish
> > Audacity's text from a user copying the exact same text from
> > another program.  There is no perfect way around this using this
> > scheme... maybe we could prefix the string we copy with
> > "Audacity:".  The problem would still exist, but as users would
> > be unlikely to copy that prefix with the intention of pasting it
> > into a new label, it would be less likely to occur in practice.
> >
> > > And I note it's using the system clipboard even for audio only,
> > > so knocking current text off the clipboard. Supposing I didn't
> > > have a clipboard manager and that was a clip I was just about
> > > to paste into a document? Would I have expected Audacity to
> > > erase that clip permanently when copying audio?
> >
> > Most programs operate on the system clipboard when you use
> > Edit->Copy. Some programs (i.e. vim) have separate cut buffers,
> > but you explicitly control when you use them.  I wouldn't expect
> > Audacity to act any differently.
>
> Vim is a text editor, so not fully relevant. Users will expect a
>  text editor to use the system clipboard, unless it has its own
>  specialist clipboard. I'll admit I don't have many "other" audio
>  editors on my computer, but Goldwave and CoolEditPro both use
>  their own internal clipboard for audio data, as Audacity always
>  did before today (CEP has options to use the Windows clipboard).
>
> I believe your change (at least for "audio data only") will not be
> universally welcomed and will lead to "bug reports", especially for
> users switching from 1.2. So I'd like to be convinced please, if
>  your scheme is necessary for capturing "audio-with-label", why it
>  is necessary for "audio-only".
 

[Al Dimond]

On Tuesday 03 November 2009 23:15:10 Gale (Audacity Team) wrote:

> "Al Dimond" wrote
>
> > I thought it might be very common that a user could
> > [[A]] have some text on the clipboard, then copy some audio in
> > Audacity, paste that audio somewhere, then copy the same text as
> > before over again, expecting to be able to paste it into a new
> > label.  Under that scheme, the second copy would be invisible.
> > Under the scheme I used, the only invisible copies are ones that
> > have the same text as Audacity's generated clipboard text.  It's
> > still possible, but less likely.
>
> Exactly, it's a possible flaw.
>
> > I think it would be great to rip this out, because it's sort of
> > ugly, and it's always possible to game it.  We'd just have to
> > agree that Edit->Paste should only check the system clipboard
> > during label edit, and possibly create a new menu command like
> > "Paste text into new label" (not that it's very hard to go Ctrl-B
> > Ctrl-V).  That would mean a change in behavior for anyone that's
> > used to [[B]] copying something from
> > Notepad, clicking in a label track, hitting Ctrl-V, and getting a
> > new label with system clipboard text.  I don't really like that
> > behavior all that much, but since it existed and was definitely
> > intended as a feature I tried to preserve it where it made sense.
>
> Hi Al,
>

Good morning!

> I've only ever seen good comments about the Audacity clipboard
>  (especially it doesn't mess with the system clipboard when holding
>  audio data, and also "click in label track and type" (or "paste
>  the system clipboard"). The bad press we got was the previous mess
>  copying labels-with-audio and not being able to do it, or getting
>  system text in the label.
>

In the previous mess, we very well could *copy* label tracks, we just
couldn't *paste* them.  During the paste, if there was a label track
selected and text on the system clipboard Audacity always pasted text
from the system clipboard into all selected label tracks.

> If we rip out what we have now, we can still do [[A]] can't we (you
>  mean they already have labelled audio with system text in it, and
>  copy audio-with-label)? Plus, in the also common case where user
>  has some system text already, copies un-labelled audio, pastes it
>  and then labels it, they don't have that system text erased by
>  copying the audio as they do now.
>

If we rip out what we have now we either have to (a) limit pasting
from the system clipboard to explicit label edit situations (that is,
they're already typing in a label or choose a special "Paste text into
new label" command) or (b) go back to the mess we had before, where we
couldn't paste label tracks.  The mess we have now could probably be
improved a little, but there will always be cases where we want our
audio and get system text, with no way around that.

> I believe checking system clipboard only when doing label edits is
>  much the best - it's what we always did.
>

It's not what we always did -- before we checked the system clipboard
any time we did a paste while there was a label track selected.  That
was what caused this whole mess.

> I do think it's important we can still select over a label with its
>  own text, then
> copy and paste it with its own text. Can we still do that if we
>  change what we
> have now? Before the current change, you could actually do that,
>  and not lose
> the system clipboard, but by clicking in the audio track before
>  paste. That was
> unintuitive, but it also still let you paste the (different) system
>  text by clicking
> in the label track before paste. We don't have that possibility of
>  access to different clipboards now.
>

I wasn't aware that you could paste into a label track with only an
audio track selected.  I'm surprised that worked -- usually paste only
pastes into selected tracks -- and I never would have guessed it would
work, even after reading the code to OnPaste() many times.  An any
rate, you couldn't paste audio and label tracks together in the
logical way, or paste just a region of a label track you'd just
copied, which was wrong.

> If (previous behaviour) people can find the right-click to paste
>  system text into
> a pre-existing label while the Audacity clipboard holds some other
>  text, then I
> don't think it's unreasonable when they want [[B]] to right-click
>  at a point in the
> label track to paste that other text (or some menu option different
>  from "Paste").
> My feedback was that people like the idea of the system and
>  Audacity clipboard
> having different contents. I'm not keen to throw that away, or keen
>  to have the system clipboard wiped whenever we copy. I'm
>  interested in other views/ use cases though.
>
>

Personally I don't care at all about wiping the system clipboard,
seeing as we're living in a world where obnoxious web developers
overwrite your clipboard with marketing URLs once per second -- what
I'm saying is that it's a transient thing.  But I don't really care
for my current implementation either, though.

If it's OK for Audacity to *never* check the system clipboard except
during a label edit, and perhaps while executing the new menu command,
"Paste text into new label", then I'd feel good about getting rid of
all the system clipboard stuff I added.

 - Al

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Wednesday 04 November 2009 08:06:54 Al Dimond wrote:
> If it's OK for Audacity to *never* check the system clipboard
>  except during a label edit, and perhaps while executing the new
>  menu command, "Paste text into new label", then I'd feel good
>  about getting rid of all the system clipboard stuff I added.
>

Right now I have a change like this sitting in my tree.  There is a
new menu command, called "Paste Te&xt to New Label", shortcut
Ctrl+Alt+V, that pastes clipboard text to a new label in all the
selected label tracks (if there are none it selects the first label
track after the first selected track; if there are none of those it
creates a new label track -- in this way it works sort of like "Add
Label").  And when you use Edit->Paste, unless you are editing the
text of a label, the system clipboard is ignored.

If that sounds good to everyone I'll commit it.

 - Al

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

Al said:
> Personally I don't care at all about wiping the system clipboard

I do, and you'll find others do, so I don't think we should do it.
Plus, clipboard managers will store everything copied to the
clipboard which will then have to be cleaned out. Plus, with
what we have now, you can't grab the system text you want
before you copy, because the copy will wipe the system text.
That's way too inflexible IMHO.  

See below.

| From Al Dimond <[hidden email]>
| Wed, 4 Nov 2009 12:12:18 -0700
| Subject: [Audacity-devel] Audacity Clipboard WAS Re: Large commit coming -- VS project will need updating

> On Wednesday 04 November 2009 08:06:54 Al Dimond wrote:
> > If it's OK for Audacity to *never* check the system clipboard
> >  except during a label edit, and perhaps while executing the new
> >  menu command, "Paste text into new label", then I'd feel good
> >  about getting rid of all the system clipboard stuff I added.
> >
>
> Right now I have a change like this sitting in my tree.  There is a
> new menu command, called "Paste Te&xt to New Label", shortcut
> Ctrl+Alt+V, that pastes clipboard text to a new label in all the
> selected label tracks (if there are none it selects the first label
> track after the first selected track; if there are none of those it
> creates a new label track -- in this way it works sort of like "Add
> Label").  And when you use Edit->Paste, unless you are editing the
> text of a label, the system clipboard is ignored.
>
> If that sounds good to everyone I'll commit it.

What will happen in this new scheme if user clicks in an existing
label track and CTRL + V - they get the Audacity clipboard? But
if they use "Paste Te&xt to New Label" they get the system
clipboard?

Is this new command in the Edit Menu? I still think it should be
available on right-click as well when in empty space in an existing
label track, because it will be easier found that way by people who
use the analogous command for editing an existing label.

Please make the shortcut CTRL + SHIFT + V (it seems to be free).
ALT commands don't work on Mac as I understand it. Bill will
correct me if I'm wrong.


Thanks, Al.



Gale

 

 

     

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Bill Wharrie]

On 4-Nov-09, at 3:31 PM, Gale Andrews wrote:

>
> Please make the shortcut CTRL + SHIFT + V (it seems to be free).
> ALT commands don't work on Mac as I understand it. Bill will
> correct me if I'm wrong.
>


:-)

On Mac, ALT = OPTION, CTRL = COMMAND (AKA apple key)

So, CTRL + ALT + V becomes COMMAND + OPTION + V on Mac.

-- Bill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Wednesday 04 November 2009 13:31:52 Gale Andrews wrote:

> Al said:
> > Personally I don't care at all about wiping the system clipboard
>
> I do, and you'll find others do, so I don't think we should do it.
> Plus, clipboard managers will store everything copied to the
> clipboard which will then have to be cleaned out. Plus, with
> what we have now, you can't grab the system text you want
> before you copy, because the copy will wipe the system text.
> That's way too inflexible IMHO.
>
> See below.
>
> | From Al Dimond <[hidden email]>
> | Wed, 4 Nov 2009 12:12:18 -0700
> | Subject: [Audacity-devel] Audacity Clipboard WAS Re: Large commit
> | coming -- VS project will need updating
> |
> > On Wednesday 04 November 2009 08:06:54 Al Dimond wrote:
> > > If it's OK for Audacity to *never* check the system clipboard
> > >  except during a label edit, and perhaps while executing the
> > > new menu command, "Paste text into new label", then I'd feel
> > > good about getting rid of all the system clipboard stuff I
> > > added.
> >
> > Right now I have a change like this sitting in my tree.  There is
> > a new menu command, called "Paste Te&xt to New Label", shortcut
> > Ctrl+Alt+V, that pastes clipboard text to a new label in all the
> > selected label tracks (if there are none it selects the first
> > label track after the first selected track; if there are none of
> > those it creates a new label track -- in this way it works sort
> > of like "Add Label").  And when you use Edit->Paste, unless you
> > are editing the text of a label, the system clipboard is ignored.
> >
> > If that sounds good to everyone I'll commit it.
>
> What will happen in this new scheme if user clicks in an existing
> label track and CTRL + V - they get the Audacity clipboard? But
> if they use "Paste Te&xt to New Label" they get the system
> clipboard?
>
> Is this new command in the Edit Menu?

It's currently in the Edit menu right underneath Paste.

> I still think it should be
> available on right-click as well when in empty space in an existing
> label track, because it will be easier found that way by people who
> use the analogous command for editing an existing label.
>

I'll look into how to create a little context menu, but if we're going
to use context menus for this we should have a real plan for them
post-2.0... otherwise we'll wind up with uncontrolled context menu
sprawl.  A well-designed set of context menus could be a good addition
to Audacity, and we don't do much with right-clicks at this point.

> Please make the shortcut CTRL + SHIFT + V (it seems to be free).
> ALT commands don't work on Mac as I understand it. Bill will
> correct me if I'm wrong.
>

I actually had Ctrl+Shift+V first, then noticed a couple analogous
situations where we used Ctrl+Alt+Letter.  It works fine on Mac; Ctrl
gets changed to Command and Alt to Option, which are represented in
menus by strange hieroglyphs that also serve to communicate secret
messages straight from Cupertino to the Macintosh Legion.  The Command
symbol burns red in the east.  The hour draws near.  The Macintosh
Legion takes no prisoners, only YOUR RIGHT MOUSE BUTTON.

 - Al

>
> Thanks, Al.
>
>
>
> Gale
>
>

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Al Dimond <[hidden email]>
| Wed, 4 Nov 2009 14:00:18 -0700
| Subject: [Audacity-devel] Audacity Clipboard WAS Re: Large commit coming -- VS project will need updating

> On Wednesday 04 November 2009 13:31:52 Gale Andrews wrote:
> > | From Al Dimond <[hidden email]>
> > | Wed, 4 Nov 2009 12:12:18 -0700
> > | Subject: [Audacity-devel] Audacity Clipboard WAS Re: Large commit
> > | coming -- VS project will need updating
> > |
> > > On Wednesday 04 November 2009 08:06:54 Al Dimond wrote:
> > > > If it's OK for Audacity to *never* check the system clipboard
> > > >  except during a label edit, and perhaps while executing the
> > > > new menu command, "Paste text into new label", then I'd feel
> > > > good about getting rid of all the system clipboard stuff I
> > > > added.
> > >
> > > Right now I have a change like this sitting in my tree.  There is
> > > a new menu command, called "Paste Te&xt to New Label", shortcut
> > > Ctrl+Alt+V, that pastes clipboard text to a new label in all the
> > > selected label tracks (if there are none it selects the first
> > > label track after the first selected track; if there are none of
> > > those it creates a new label track -- in this way it works sort
> > > of like "Add Label").  And when you use Edit->Paste, unless you
> > > are editing the text of a label, the system clipboard is ignored.
> > >
> > > If that sounds good to everyone I'll commit it.
> >
> > What will happen in this new scheme if user clicks in an existing
> > label track and CTRL + V - they get the Audacity clipboard? But
> > if they use "Paste Te&xt to New Label" they get the system
> > clipboard?
> >
> > Is this new command in the Edit Menu?
>
> It's currently in the Edit menu right underneath Paste.

Perfect.

> > I still think it should be
> > available on right-click as well when in empty space in an existing
> > label track, because it will be easier found that way by people who
> > use the analogous command for editing an existing label.
> >
>
> I'll look into how to create a little context menu, but if we're going
> to use context menus for this we should have a real plan for them
> post-2.0... otherwise we'll wind up with uncontrolled context menu
> sprawl.  A well-designed set of context menus could be a good addition
> to Audacity, and we don't do much with right-clicks at this point.

I agree about "sprawl"  (I think my suggestion is "targeted")  but also
that we really don't use context menus enough. Windows users pretty
much expect them, they do speed up workflow for sighted users and
we're often asked for them:
http://wiki.audacityteam.org/index.php?title=Feature_Requests#Other_Interface_Tweaks

Probably this needs yet another Wiki page in the "Feature Planning"
category to discuss what to do...



> > Please make the shortcut CTRL + SHIFT + V (it seems to be free).
> > ALT commands don't work on Mac as I understand it. Bill will
> > correct me if I'm wrong.
> >
>
> I actually had Ctrl+Shift+V first, then noticed a couple analogous
> situations where we used Ctrl+Alt+Letter.  It works fine on Mac; Ctrl
> gets changed to Command and Alt to Option...

As Bill also told me - I forgot you have access to a Mac now as well.
I'll try and remember this Mac behaviour once and for all.

CTRL + ALT + letter is more correct, I think, as long as it works.  

But what you really *can't* do on the Mac is use Option to access the
menus as you can with ALT on Windows and Linux. I hope I have that
correct, anyway?



Gale


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel