With 1.3.13-beta rc1:
New Project
Import WAV or AIF with "read directly"
Save project - "copy in?" dialog appears
Close project
Re-open project
Make an edit
Save project - the "copy in?" dialog does not appear
File > Check Dependencies still shows the dependency
I'm not sure if this is a bug or not. The preference reads "When
saving a project that depends on other files ... Ask User" which
implies to me that the user should be asked on every save as long as
the "Ask User" option is set. That could get annoying for someone who
saves often and does not want to copy the file in, but then they could
just check "Don't ask me again". So before raising this on Bugzilla
I'd like some feedback.
-- Bill

Sorry you did not like my post, but I could not do research while mobile. It
does not appear to me that there is a bugzilla addon to manage long threads
(although there are a few changelog generators that might be handy for
release notes, but that's another thread). So I say +1 to moving complicated
discussions to the Wiki.
--Ashton
On Tue, Mar 29, 2011 at 3:18 PM, James Crook <crookj@...> wrote:
> On 29/03/2011 20:55, Ashton Kemerling wrote:
>
> Maybe there's a mod, or one could make a mod, to collapse all but the last
> n comments?
>
> --Ashton
>
> Ashton - that is not a helpful response. To be helpful you would at least
> have looked on the internet and found one or looked on the web and not found
> one and reported back.
>
> This thread already had 10 messages in it. You made it 11 adding almost no
> value.
>
> We agree that threads are getting too long.
> We agree that at least sometimes it makes sense to split a bug.
> We agree that one part of the problem is lack of summarization.
> We agree that summary bugs can be a good thing if used judiciously.
>
> Myself, Vaughan, Gale are OK with the idea of at least having some use of
> wiki for some aspect of bug discussion.
>
> After the release we will look at some of the open issues that have very
> long comment trails and see if it makes sense to have a summary page for
> each in the wiki.
>
> --James.
>
>
>
>
> Sent from my mobile device
>
> On Mar 29, 2011 2:49 PM, "Gale Andrews" <gale@...> wrote:
>
>
> | From AshtonKemerling@...
> | Tue, 29 Mar 2011 16:49:12 +0000
>
> | Subject: [Audacity-quality] Long threads in Bugzilla.
>
> > I don't think I explained my point well enough. I think if the
> discussions
> > are getting so long...
> If the issue is "too broad" or "not broad, but multiple solutions being
> proposed", a single Wiki page to discuss would I think be potentially
> helpful. We could use the space to discuss how to make "less broad".
>
> We shouldn't split a "not broad, focused" bug just because it needs
> discussion (as I think you agree).
>
> Summary bugs can be very useful for QA management. Fragmentation
> of closely related sub-issues to their own bugs can make that harder.
>
>
>
> > Are there plugins or mods for Bugzilla that allow for threaded
> discussions,
> > like the many e...
> I think the issue is there are too many messages in the thread already,
> and no means to trim them down to the "current position", removing
> details of the audit trail that are now superfluous.
>
>
>
>
> Gale
>
>
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>

On 29/03/2011 20:55, Ashton Kemerling wrote:
>
> Maybe there's a mod, or one could make a mod, to collapse all but the
> last n comments?
>
> --Ashton
>
Ashton - that is not a helpful response. To be helpful you would at
least have looked on the internet and found one or looked on the web and
not found one and reported back.
This thread already had 10 messages in it. You made it 11 adding almost
no value.
We agree that threads are getting too long.
We agree that at least sometimes it makes sense to split a bug.
We agree that one part of the problem is lack of summarization.
We agree that summary bugs can be a good thing if used judiciously.
Myself, Vaughan, Gale are OK with the idea of at least having some use
of wiki for some aspect of bug discussion.
After the release we will look at some of the open issues that have very
long comment trails and see if it makes sense to have a summary page for
each in the wiki.
--James.
> Sent from my mobile device
>
>> On Mar 29, 2011 2:49 PM, "Gale Andrews" <gale@...
>> <mailto:gale@...>> wrote:
>>
>>
>> | From AshtonKemerling@... <mailto:AshtonKemerling@...>
>> | Tue, 29 Mar 2011 16:49:12 +0000
>>
>> | Subject: [Audacity-quality] Long threads in Bugzilla.
>>
>> > I don't think I explained my point well enough. I think if the
>> discussions
>> > are getting so long...
>>
>> If the issue is "too broad" or "not broad, but multiple solutions being
>> proposed", a single Wiki page to discuss would I think be potentially
>> helpful. We could use the space to discuss how to make "less broad".
>>
>> We shouldn't split a "not broad, focused" bug just because it needs
>> discussion (as I think you agree).
>>
>> Summary bugs can be very useful for QA management. Fragmentation
>> of closely related sub-issues to their own bugs can make that harder.
>>
>>
>>
>> > Are there plugins or mods for Bugzilla that allow for threaded
>> discussions,
>> > like the many e...
>>
>> I think the issue is there are too many messages in the thread already,
>> and no means to trim them down to the "current position", removing
>> details of the audit trail that are now superfluous.
>>
>>
>>
>>
>> Gale

Maybe there's a mod, or one could make a mod, to collapse all but the last n
comments?
--Ashton
Sent from my mobile device
On Mar 29, 2011 2:49 PM, "Gale Andrews" <gale@...> wrote:
| From AshtonKemerling@...
| Tue, 29 Mar 2011 16:49:12 +0000
| Subject: [Audacity-quality] Long threads in Bugzilla.
> I don't think I explained my point well enough. I think if the discussions
> are getting so long...
If the issue is "too broad" or "not broad, but multiple solutions being
proposed", a single Wiki page to discuss would I think be potentially
helpful. We could use the space to discuss how to make "less broad".
We shouldn't split a "not broad, focused" bug just because it needs
discussion (as I think you agree).
Summary bugs can be very useful for QA management. Fragmentation
of closely related sub-issues to their own bugs can make that harder.
> Are there plugins or mods for Bugzilla that allow for threaded
discussions,
> like the many e...
I think the issue is there are too many messages in the thread already,
and no means to trim them down to the "current position", removing
details of the audit trail that are now superfluous.
Gale
> On , Gale Andrews <gale@...> wrote:
>
>
> > | From Ashton Kemerling ashtonkemerli...
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and...

| From Ashton Kemerling <ashtonkemerling@...>
| Sun, 27 Mar 2011 12:00:38 -0500
| Subject: [Audacity-quality] Long threads in Bugzilla.
> -1 for taking discussions off Bugzilla. I think -devel is a great place to
> discuss long term goals, and non bug specific items (like release dates and
> processes), but I dislike how it can fragment when discussing specific issues.
> I like having one central area to discuss bug specific issues. If bug
> discussions are getting too long, I see one of two possible fixes:
>
> 1) We need to figure out why often discussed bugs are remaining open for so
> long.
>
> 2) If the discussion is going in multiple ways, we need to either make votes
> on where to go, or split the bug into multiple bugs, each representing the
> distinct issues raised in the bug discussion.
I always like having "one central place", but splitting bugs can
sometimes be undesirable for QA purposes. I would rather move
extended discussions to Wiki than split bugs purely because of a
crass limitation in the bug tracker.
Gale
> On Sunday, March 27, 2011 11:12:10 AM Steve the Fiddle wrote:
> > Ed Musgrove asked me to forward his message to QA:
> > Steve
> >
> > --- Start ---
> > I don't post on QA but do read it online, would you add this to the thread
> > please?
> >
> > On audacity-QA Steve said:
> > > On 3/26/2011 4:11 PM, James Crook wrote:
> > >> Suppose we were occasionally to use the URL field in
> > >> Bugzilla to link to a wiki page?
> > >
> > >or how about a board on the forum?
> >
> > -1 discussions on Bugzilla
> > +1 forum
> >
> > The wiki is a nightmare for discussions: no idea who said what when, no
> > code blocks, difficult quoting, must learn an entirely new coding language
> > to post.
> >
> > On Bugzilla there is only one URL field which is already in use on a number
> > of bugs. If we hijack it for a link to any discussion page we lose current
> > functionality. Can a second URL field be added?
> >
> > --- End ---
> >
> > On Sun, Mar 27, 2011 at 3:34 PM, James Crook <crookj@...> wrote:
> > > On 27/03/2011 13:43, Steve the Fiddle wrote:
> > >> +1 for extended discussions not being on Bugzilla.
> > >>
> > >>>> Suppose we were occasionally to use the URL field in Bugzilla to link
> > >>>> to a wiki page?<snip>
> > >>
> > >> or how about a board on the forum?
> > >
> > > -1
> > > The point about wiki is that we can summarize. Forum is as thread-mode
> > > as Bugzilla.
> > >
> > > --James.
> > >
> > > -------------------------------------------------------------------------
> > > ----- Enable your software for Intel(R) Active Management Technology to
> > > meet the growing manageability and security demands of your customers.
> > > Businesses are taking advantage of Intel(R) vPro (TM) technology - will
> > > your software be a part of the solution? Download the Intel(R)
> > > Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
> > > _______________________________________________
> > > Audacity-quality mailing list
> > > Audacity-quality@...
> > > https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >
> > ---------------------------------------------------------------------------
> > --- Enable your software for Intel(R) Active Management Technology to meet
> > the growing manageability and security demands of your customers.
> > Businesses are taking advantage of Intel(R) vPro (TM) technology - will
> > your software be a part of the solution? Download the Intel(R)
> > Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Audacity-quality mailing list
> > Audacity-quality@...
> > https://lists.sourceforge.net/lists/listinfo/audacity-quality

| From Steve the Fiddle <stevethefiddle@...>
| Sun, 27 Mar 2011 17:12:10 +0100
| Subject: [Audacity-quality] Long threads in Bugzilla.
> Ed Musgrove asked me to forward his message to QA:
>
> On audacity-QA Steve said:
> > On 3/26/2011 4:11 PM, James Crook wrote:
> >> Suppose we were occasionally to use the URL field in
> >> Bugzilla to link to a wiki page?
>
> >or how about a board on the forum?
>
> -1 discussions on Bugzilla
> +1 forum
>
> The wiki is a nightmare for discussions: no idea who said what when, no code
> blocks, difficult quoting, must learn an entirely new coding language to
> post.
>
> On Bugzilla there is only one URL field which is already in use on a number
> of bugs. If we hijack it for a link to any discussion page we lose current
> functionality. Can a second URL field be added?
There is a "bug URL" supposedly for bugs in "other installations":
http://bugzilla.audacityteam.org/page.cgi?id=fields.html#see_also
I see no reason we could not hijack that.
I don't object quite so much as others to long bugzilla threads, mainly
because I'm following them on a daily basis anyway. And I'm used to
long threads on the Forum too.
We pretty much knew when we went to Bugzilla that we would be
coming back to Wiki to some degree because of Bugzilla's
inflexibility. I don't think inserting code/attachments/images is
that much harder on Wiki than Forum. I find Forum BBCode even
more cumbersome than Wiki formatting. Quotes are usually handled
on the Wiki by bulletting underneath what you want to reply to. You
can use <pre> or the two code templates for code.
Forum is not quite so helpless as bugzilla, though you would need an
admin account to be able to delete and manipulate threads. I would
not go as far as -1 on it, though I think Wiki is better.
As I proposed off list, I would also suggest something like a "Current
Summary" box so someone coming to the bug afresh can get the gist.
It wouldn't take HTML (unless someone can hack an extra HTML box),
but it could help for bugs we don't outsource to Wiki (or even if we
do).
Generally, I can't understand why there are no extensions, no easy
hacks for bugzilla.
Gale
> On Sun, Mar 27, 2011 at 3:34 PM, James Crook <crookj@...> wrote:
> > On 27/03/2011 13:43, Steve the Fiddle wrote:
> >> +1 for extended discussions not being on Bugzilla.
> >>>> Suppose we were occasionally to use the URL field in Bugzilla to link to
> >>>> a wiki page?<snip>
> >> or how about a board on the forum?
> >
> > -1
> > The point about wiki is that we can summarize. Forum is as thread-mode
> > as Bugzilla.
> >
> > --James.

-1 for taking discussions off Bugzilla. I think -devel is a great place to
discuss long term goals, and non bug specific items (like release dates and
processes), but I dislike how it can fragment when discussing specific issues.
I like having one central area to discuss bug specific issues. If bug
discussions are getting too long, I see one of two possible fixes:
1) We need to figure out why often discussed bugs are remaining open for so
long.
2) If the discussion is going in multiple ways, we need to either make votes
on where to go, or split the bug into multiple bugs, each representing the
distinct issues raised in the bug discussion.
--Ashton
On Sunday, March 27, 2011 11:12:10 AM Steve the Fiddle wrote:
> Ed Musgrove asked me to forward his message to QA:
> Steve
>
> --- Start ---
> I don't post on QA but do read it online, would you add this to the thread
> please?
>
> On audacity-QA Steve said:
> > On 3/26/2011 4:11 PM, James Crook wrote:
> >> Suppose we were occasionally to use the URL field in
> >> Bugzilla to link to a wiki page?
> >
> >or how about a board on the forum?
>
> -1 discussions on Bugzilla
> +1 forum
>
> The wiki is a nightmare for discussions: no idea who said what when, no
> code blocks, difficult quoting, must learn an entirely new coding language
> to post.
>
> On Bugzilla there is only one URL field which is already in use on a number
> of bugs. If we hijack it for a link to any discussion page we lose current
> functionality. Can a second URL field be added?
>
> --- End ---
>
> On Sun, Mar 27, 2011 at 3:34 PM, James Crook <crookj@...> wrote:
> > On 27/03/2011 13:43, Steve the Fiddle wrote:
> >> +1 for extended discussions not being on Bugzilla.
> >>
> >>>> Suppose we were occasionally to use the URL field in Bugzilla to link
> >>>> to a wiki page?<snip>
> >>
> >> or how about a board on the forum?
> >
> > -1
> > The point about wiki is that we can summarize. Forum is as thread-mode
> > as Bugzilla.
> >
> > --James.
> >
> > -------------------------------------------------------------------------
> > ----- Enable your software for Intel(R) Active Management Technology to
> > meet the growing manageability and security demands of your customers.
> > Businesses are taking advantage of Intel(R) vPro (TM) technology - will
> > your software be a part of the solution? Download the Intel(R)
> > Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
> > _______________________________________________
> > Audacity-quality mailing list
> > Audacity-quality@...
> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ---------------------------------------------------------------------------
> --- Enable your software for Intel(R) Active Management Technology to meet
> the growing manageability and security demands of your customers.
> Businesses are taking advantage of Intel(R) vPro (TM) technology - will
> your software be a part of the solution? Download the Intel(R)
> Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

Ed Musgrove asked me to forward his message to QA:
Steve
--- Start ---
I don't post on QA but do read it online, would you add this to the thread
please?
On audacity-QA Steve said:
> On 3/26/2011 4:11 PM, James Crook wrote:
>> Suppose we were occasionally to use the URL field in
>> Bugzilla to link to a wiki page?
>or how about a board on the forum?
-1 discussions on Bugzilla
+1 forum
The wiki is a nightmare for discussions: no idea who said what when, no code
blocks, difficult quoting, must learn an entirely new coding language to
post.
On Bugzilla there is only one URL field which is already in use on a number
of bugs. If we hijack it for a link to any discussion page we lose current
functionality. Can a second URL field be added?
--- End ---
On Sun, Mar 27, 2011 at 3:34 PM, James Crook <crookj@...> wrote:
> On 27/03/2011 13:43, Steve the Fiddle wrote:
>> +1 for extended discussions not being on Bugzilla.
>>>> Suppose we were occasionally to use the URL field in Bugzilla to link to
>>>> a wiki page?<snip>
>> or how about a board on the forum?
>
> -1
> The point about wiki is that we can summarize. Forum is as thread-mode
> as Bugzilla.
>
> --James.
>
> ------------------------------------------------------------------------------
> Enable your software for Intel(R) Active Management Technology to meet the
> growing manageability and security demands of your customers. Businesses
> are taking advantage of Intel(R) vPro (TM) technology - will your software
> be a part of the solution? Download the Intel(R) Manageability Checker
> today! http://p.sf.net/sfu/intel-dev2devmar
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

On 27/03/2011 13:43, Steve the Fiddle wrote:
> +1 for extended discussions not being on Bugzilla.
>>> Suppose we were occasionally to use the URL field in Bugzilla to link to
>>> a wiki page?<snip>
> or how about a board on the forum?
-1
The point about wiki is that we can summarize. Forum is as thread-mode
as Bugzilla.
--James.

On Sat, Mar 26, 2011 at 11:38 PM, Vaughan Johnson
<vaughan@...> wrote:
> +1 on the proposal, James. Thanks!
>
> - V
>
>
> On 3/26/2011 4:11 PM, James Crook wrote:
>> As predicted when I talked about the ideal bugtracker... We're having
>> problems with Bugzilla that are in part caused by its design being built
>> around an audit trail. That is almost the opposite of what we want,
>> where we want to know where we are now, and only very rarely how we got
>> here. Bugs like Bug 26 are a devil to read through because there is so
>> much in it..
+1 for extended discussions not being on Bugzilla.
>>
>> Orgs like Ubuntu avoid some of our problems by NOT discussing
>> solutions and proposed solutions and variants of proposed solutions
>> in the bugtracker. They tend to avoid discussion in the bugtracker
>> and just use it for initial bug reports, and reported DEVEL-FIXEDs.
>>
>>
>> Suppose we were occasionally to use the URL field in Bugzilla to link to
>> a wiki page? <snip>
>
or how about a board on the forum?
Inserting code, attachments, images and quoting previous posts is very
much quicker and easier on phpBB than on Mediawiki.
Those that want to can subscribe to that specific forum board and be
notified by e-mail when there is a new topic, and/or subscribe to a
specific topic and be notified when there is a new post to that topic.
Easier and quicker posting means less time wasted.
The board's topic list makes it easier to get an overview of current
discussions.
Posting to the forum could also be very much better for getting new
patches tested.
Steve

+1 on the proposal, James. Thanks!
- V
On 3/26/2011 4:11 PM, James Crook wrote:
> As predicted when I talked about the ideal bugtracker... We're having
> problems with Bugzilla that are in part caused by its design being built
> around an audit trail. That is almost the opposite of what we want,
> where we want to know where we are now, and only very rarely how we got
> here. Bugs like Bug 26 are a devil to read through because there is so
> much in it..
>
> Orgs like Ubuntu avoid some of our problems by NOT discussing
> solutions and proposed solutions and variants of proposed solutions
> in the bugtracker. They tend to avoid discussion in the bugtracker
> and just use it for initial bug reports, and reported DEVEL-FIXEDs.
>
>
> Suppose we were occasionally to use the URL field in Bugzilla to link to
> a wiki page? <snip>

As predicted when I talked about the ideal bugtracker... We're having
problems with Bugzilla that are in part caused by its design being built
around an audit trail. That is almost the opposite of what we want,
where we want to know where we are now, and only very rarely how we got
here. Bugs like Bug 26 are a devil to read through because there is so
much in it..
Orgs like Ubuntu avoid some of our problems by NOT discussing
solutions and proposed solutions and variants of proposed solutions
in the bugtracker. They tend to avoid discussion in the bugtracker
and just use it for initial bug reports, and reported DEVEL-FIXEDs.
Suppose we were occasionally to use the URL field in Bugzilla to link to
a wiki page? Not for short bugs where it is just extra work, but for
hydra bugs, where the dynamic of what is in the bug keeps changing or is
disputed, or proposed solutions keep changing? So a bug that is clearly
defined, repeatable, is clearly a bug, has a fix that clears the
reported issue does not need a wiki page. Where we do have a wiki page,
we call it by the bug number, and we start with a summary of the issue.
Because wiki has a history, we can if we want to dig back into past
descriptions.
We'd then use our bug tracker more like Ubuntu does, with the discussion
and proposals and so on happening on wiki.
I am raising it as a suggestion at the moment, testing the water.
----
What prompted it was
http://bugzilla.audacityteam.org/show_bug.cgi?id=329
"Triggering behaviour for "Files Missing" warning"
where I do not want to continue that discussion actually in the bugtracker!
> (In reply tocomment #6 <http://bugzilla.audacityteam.org/show_bug.cgi?id=329#c6&gt;)
> > One of the tests to do is to go through various warning scenarios, then
> > restore the missing linked-to file. If Audacity recovers gracefully then
> > we are doing the right thing wrt modifying the underlying project.
> > It does in the tests I've done. My concern was that we were replacing audio
> > by silence and then treating the silence exactly as if it were real silence
> > having forgotten it was missing audio. That would prevent correct recovery
> > and prevent us giving follow-up warnings when we ideally should.
> Yes I was thinking about this and what advice we should give. I have tried
> briefly on Win and Ubuntu and I think its OK if you undo the edits made when
> the audio was missing. But if you delete the file, amplify a region, and
> restore the audio, you still have missing audio at that region, plus silence
> either side of the region as well, if that happened. Saving the project like
> that doesn't restore the amplified original audio or the audio either side of
> it, when you reopen the project with the audio in situ.
>
> I think this is a new bug if we want to pursue it. Can we restore the intended
> amplify without undo and redo (once the audio is restored)? I'd be surprised
> without some kind of project refresh, so if not, should we warn on export or
> project save? I think perhaps we should, though maybe not a P2.
We could also automatically do the undo when we detect the problem.
> > You've been pushing back on me splitting bugs, so I didn't want to create a
> > new long-term feature enhancement request for fast OD background copy-in.
> > If you think it helps, create it.
> We should talk about communicating better and earlier, James.
+1. Suggested wiki approach might be one way to do it, which does not
require us to be on IRC/Chat at the same time. For each bug we could
try to keep undisputed facts on the page, and talk on the talk page.
> I should split
> more than I do, but I had very specific reasons why I did not want to split bug
> 26 when the programming "fixed" rationale was below the standard for a QA
> "fixed". Also I am not usually keen on splitting where the bug is demonstrably
> a summary bug and/or this creates bugs that share the same release note. That's
> messy with only a manual system of retrieving release notes.
Yes. And the release note problem is also because we have one release
note per P3 bug, and can't share them.
One possibility is to create summary bugs that are presentations of P3
bugs, as the user would want to hear them.
> I would split out a "background-copy-in-during-OD" feature enhancement. You, I
> and (from the Wiki) Peter support it. That looks enough support to me, unless
> people come in here with -1's. I am concerned how much it would slow up OD, but
> we should still try it. On a pop-track-length WAV, copy-in might even complete
> before they had time to mess with the file.
Worth adding such an issue even if there is a -1. If it turns out 'It's
impossible' we'll all flip to -1 and we can close it as WONT-FIX - but I
think that is unlikely. The worst effect is likely to be when you try
to close a project and it says "Still copying audio into project.... If
you close now you should not move delete or rename the source audio.
Close now? [yes|No]" or something like that.
> > not a diktat that we should have such a 'hint' dialog. I don't want us
> > to be checking 100 files before each operation in the case that the user
> > has a project in which they link in lots of small files.
> Agreed, but if we don't have your hint dialogues, we could abandon the check
> after the first missing aliased file is detected (for the purposes of putting
> up a single warning that doesn't reappear if dismissed in that playback
> session). That should avoid some multi-warnings and desync.
The point is that there may be no missing audio. When that is so
Audacity will be checking 100 files with every operation.
> > I probably should make a more general point that the hint dialogs Large->
> > file->'Why not use Linking (it's faster)' Small-Files->'Why not use copying
> > (it's safer)' are things that would annoy me and I'd switch off immediately.
> > Because I don't want them, it makes it harder for me to see what would be
> > right for a new Audacity user.
> I guess I am the arch protector of novices but ATM I don't really see the need
> for these messages if we can fixbug 324 <http://bugzilla.audacityteam.org/show_bug.cgi?id=324&gt; as I propose, which is mission
> critical for me.
Bug 324 is currently a P2. It is also not hard to do, and with you
backing it strongly, and Bill too, it is likely not to be ignored.
--James.

| From Vaughan Johnson <vaughan@...>
| Mon, 24 Jan 2011 08:25:56 -0800
| Subject: [Audacity-quality] Controls text lacks colons in Generators
> On 1/23/2011 4:44 AM, James Crook wrote:
> > Gale,
> >
> > +1
> >
> > Right aligning 'Duration' is a clear improvement. Adding missing ":" is
> > good for consistency. Avoiding breaking translation the way you have is
> > also the right thing to do (TM).
>
> It's the right thing to do only in this circumstance, because we want to
> avoid extra translating tasks. If I came upon that code a year from now,
> with no explanation attached, I'd wonder why on earth it isn't just part
> of the string. So, Gale, please add a comment about why it's that way,
> and a "TODO: make it part of the string after 2.0".
Done, with comment/TODO. Sorry it took a while.
> Frankly, I don't think it would be terrible to just put it in the string
> and just not necessarily translate it.
I think that's what normally happens when writing new code. It looks
cleaner in the code, but I'm not sure it helps translators to know they
may be translating text for a control. Looking at some of the translations
for controls, it looks like the colons are quite likely to be randomly
removed by translators so there is some advantage in leaving them
out of the string.
> Also, is it correct in all cases -- what's the right place for the colon for
> languages that read right-to-left?
Given a native OS installation in (for example) Hebrew would reverse
the entire interface, right-justifying would be correct, I think. You would
get the end of the text and the colon abutting the control, as for left-to-right.
Gale
> >
> > I've looked at the code in the patch and that looks just fine too. No
> > one is working on chirp and tone effects at the moment. These are good
> > changes. You have flight clearance to check them in :-)
> >
> > Best,
> >
> >
> > James.
> >
> >
> >
> > On 23/01/2011 10:20, gale@... wrote:
> >> When I looked at the "Generate" page in the Manual recently:
> >> http://manual.audacityteam.org/man/Generate_Menu
> >>
> >> I noticed the text to left of the controls rarely has a colon at the
> >> end which is standard elsewhere (e.g. in the other effects and in
> >> Preferences).
> >>
> >> So I had a go at fixing it (attached) if a developer would like a
> >> quick look and give a yay/nay or suggest a correction.
> >>
> >> I added a "+ wxString(wxT(":"))" to save breaking existing
> >> translations. For "Duration" in Chirp and Tone I used "S.AddPrompt"
> >> as in Dtmf and Noise instead of "S.AddFixedText". This looks better
> >> to me, as it makes the text right-justify and also centres it
> >> vertically with the TimeTextControl:
> >> http://www.gaclrecords.org.uk/Chirp_with_colons.png
> >>
> >>
> >> Gale
> >
> >
>

On Sun, Mar 20, 2011 at 8:38 PM, Gale Andrews <gale@...> wrote:
>
> | From Steve the Fiddle <stevethefiddle@...>
> | Sun, 20 Mar 2011 17:17:43 +0000
> | Subject: [Audacity-quality] View menu > History
>> If it's already been decided that "History" is preferred over "Undo
>> History" then although I don't agree, I've got no problem with that.
>> However, I thought that one of the primary reasons for beta versions
>> was for usability testing *before* a main release. I do of course
>> fully understand the urgency for the 2.0 release and I'm not pressing
>> to change anything that has already been decided on, but in the
>> broader view, "long-standing" is not a good reason to not improve
>> something (just my 2 cents).
>
> I would read it as "changing longstanding and not seriously bad
> or mismatched items without changing functionality" could be
> misleading. We did change "Control Toolbar" to "Transport
> Toolbar" not long ago, which was certainly longstanding.
>
> If the objective is maximising discoverability for undo purposes,
> I think the Edit Menu is the better place for History (once the menu
> is regrouped after 2.0).
I agree, "History" fits better alongside "Undo" and "Redo" than
alongside "Karaoke" and "Mixer Board". I also think that the meaning
of the current name (History) would be more apparent in that context.
If there is to be a reworking of the menus, then that would be the
obvious time to reconsider the History menu item.
Steve
>
> There could also be enhancements to the list such as indicating
> which tracks were edited, and saving a list of changes. That could
> argue with leaving it in the View Menu, though I don't think View >
> Show Clipping and View > Undo History sit all that well together.
> On the whole I would go for the Edit menu.
>
>
>
>
> Gale
>
>> On Fri, Mar 18, 2011 at 6:59 PM, Vaughan Johnson
>> <vaughan@...> wrote:
>> > -1. We discussed it long ago and made a decision. Changing longstanding
>> > menu command names without changing functionality is misleading. And at
>> > this point it would require lots of additional translation. Definitely
>> > not a good idea prior to 2.0.
>> >
>> > - V
>> >
>> >
>> > On 3/18/2011 7:49 AM, Steve the Fiddle wrote:
>> >> There has been some discussion on the Forum regarding the "Undo History" menu.
>> >> http://forum.audacityteam.org/viewtopic.php?f=20&t=54386
>> >> It has been suggested that it would be a lot clearer if the menu item
>> >> was called "Undo History" rather than just "History".
>> >>
>> >> Steve
>> >>
>> >
>> > ------------------------------------------------------------------------------
>> > Colocation vs. Managed Hosting
>> > A question and answer guide to determining the best fit
>> > for your organization - today and in the future.
>> > http://p.sf.net/sfu/internap-sfd2d
>> > _______________________________________________
>> > Audacity-quality mailing list
>> > Audacity-quality@...
>> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> >
>>
>> ------------------------------------------------------------------------------
>> Colocation vs. Managed Hosting
>> A question and answer guide to determining the best fit
>> for your organization - today and in the future.
>> http://p.sf.net/sfu/internap-sfd2d
>> _______________________________________________
>> Audacity-quality mailing list
>> Audacity-quality@...
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

On 3/20/2011 1:38 PM, Gale Andrews wrote:
>
> | From Steve the Fiddle <stevethefiddle@...>
> | Sun, 20 Mar 2011 17:17:43 +0000
> | Subject: [Audacity-quality] View menu > History
>> If it's already been decided that "History" is preferred over "Undo
>> History" then although I don't agree, I've got no problem with that.
>> However, I thought that one of the primary reasons for beta versions
>> was for usability testing *before* a main release.
True, but this is *very* late in the beta cycle (1.3.0 was released Nov
2005!) to be making such a change, especially because of translations.
>I do of course
>> fully understand the urgency for the 2.0 release and I'm not pressing
>> to change anything that has already been decided on, but in the
>> broader view, "long-standing" is not a good reason to not improve
>> something (just my 2 cents).
>
> I would read it as "changing longstanding and not seriously bad
> or mismatched items without changing functionality" could be
> misleading.
Right. Thanks.
>We did change "Control Toolbar" to "Transport
> Toolbar" not long ago, which was certainly longstanding.
It was really non-standard terminology and not really descriptive (there
are *many* more controls now than when it was first named "Control
Toolbar"). So yes, if there are good reasons, we can make changes.
- Vaughan

| From Steve the Fiddle <stevethefiddle@...>
| Sun, 20 Mar 2011 17:17:43 +0000
| Subject: [Audacity-quality] View menu > History
> If it's already been decided that "History" is preferred over "Undo
> History" then although I don't agree, I've got no problem with that.
> However, I thought that one of the primary reasons for beta versions
> was for usability testing *before* a main release. I do of course
> fully understand the urgency for the 2.0 release and I'm not pressing
> to change anything that has already been decided on, but in the
> broader view, "long-standing" is not a good reason to not improve
> something (just my 2 cents).
I would read it as "changing longstanding and not seriously bad
or mismatched items without changing functionality" could be
misleading. We did change "Control Toolbar" to "Transport
Toolbar" not long ago, which was certainly longstanding.
If the objective is maximising discoverability for undo purposes,
I think the Edit Menu is the better place for History (once the menu
is regrouped after 2.0).
There could also be enhancements to the list such as indicating
which tracks were edited, and saving a list of changes. That could
argue with leaving it in the View Menu, though I don't think View >
Show Clipping and View > Undo History sit all that well together.
On the whole I would go for the Edit menu.
Gale
> On Fri, Mar 18, 2011 at 6:59 PM, Vaughan Johnson
> <vaughan@...> wrote:
> > -1. We discussed it long ago and made a decision. Changing longstanding
> > menu command names without changing functionality is misleading. And at
> > this point it would require lots of additional translation. Definitely
> > not a good idea prior to 2.0.
> >
> > - V
> >
> >
> > On 3/18/2011 7:49 AM, Steve the Fiddle wrote:
> >> There has been some discussion on the Forum regarding the "Undo History" menu.
> >> http://forum.audacityteam.org/viewtopic.php?f=20&t=54386
> >> It has been suggested that it would be a lot clearer if the menu item
> >> was called "Undo History" rather than just "History".
> >>
> >> Steve
> >>
> >
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Audacity-quality mailing list
> > Audacity-quality@...
> > https://lists.sourceforge.net/lists/listinfo/audacity-quality
> >
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

If it's already been decided that "History" is preferred over "Undo
History" then although I don't agree, I've got no problem with that.
However, I thought that one of the primary reasons for beta versions
was for usability testing *before* a main release. I do of course
fully understand the urgency for the 2.0 release and I'm not pressing
to change anything that has already been decided on, but in the
broader view, "long-standing" is not a good reason to not improve
something (just my 2 cents).
Steve
On Fri, Mar 18, 2011 at 6:59 PM, Vaughan Johnson
<vaughan@...> wrote:
> -1. We discussed it long ago and made a decision. Changing longstanding
> menu command names without changing functionality is misleading. And at
> this point it would require lots of additional translation. Definitely
> not a good idea prior to 2.0.
>
> - V
>
>
> On 3/18/2011 7:49 AM, Steve the Fiddle wrote:
>> There has been some discussion on the Forum regarding the "Undo History" menu.
>> http://forum.audacityteam.org/viewtopic.php?f=20&t=54386
>> It has been suggested that it would be a lot clearer if the menu item
>> was called "Undo History" rather than just "History".
>>
>> Steve
>>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Audacity-quality mailing list
> Audacity-quality@...
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

On Sat, Mar 19, 2011 at 9:15 PM, Ashton Kemerling
<ashtonkemerling@...> wrote:
> I've got Windows 7 64 bit. I'll take a look at it tomorrow or Monday. Want
> me to try with the latest source, or the 1.3.12 release (haven't built that
> on Windows in a while).
In the forum post it looks like the bug was fixed somewhere between
.12 and svn HEAD as the user says the nightly fixes his problems.
Michael

-1. We discussed it long ago and made a decision. Changing longstanding
menu command names without changing functionality is misleading. And at
this point it would require lots of additional translation. Definitely
not a good idea prior to 2.0.
- V
On 3/18/2011 7:49 AM, Steve the Fiddle wrote:
> There has been some discussion on the Forum regarding the "Undo History" menu.
> http://forum.audacityteam.org/viewtopic.php?f=20&t=54386
> It has been suggested that it would be a lot clearer if the menu item
> was called "Undo History" rather than just "History".
>
> Steve
>