from Leland Lucius <email address hidden> 2011-04-01 00:48:46 EDT ---
>> <snip>
>> Why change several wxLogDebug() calls to wxLogMessage()? I would think that
>> type of info would only be clutter to most users, and relevant only to those of
>> us building Debug versions.
>>
> Did that because it was "hiding" what was going on when searching for the
> libraries. I felt they would assist with debugging problems when users
> complained about Audacity not finding the FFmpeg libraries. And since the
> users get Release versions, the messages wouldn't be available.
Yes, obviously I know that. Wanted to raise the issue because they formerly
were wxLogMessage() and a few months ago I changed them to wxLogDebug() because
I thought it was just cruft, and FFmpeg had been unchanged for a while. Nobody
complained, so I thought that was justified.
I think the only reason to show them in release versions is if we are actually
still getting FFmpeg errors -- but as we're using a new FFmpeg, I think yes,
leave them in at least for this release.
>
> Maybe I'm misunderstanding the reason for the log. What information in there
> does the user any good? Isn't it more for the folks that are assisting users
> with problems?
It's useful for debugging, too. :-)
And some wxLogDebug() calls are good to leave in, although probably many should
be commented out when the debugging is completed.
>
>> I see these changes are not backward compatible, but if Gale's okay with that
>> for users, I say commit this patch.
>
> How far back do you want it to go?
I wasn't advocating for *any* backward compatibility, personally. Just wanted
to double check with Gale because I said commit the patch, but that question
had not been resolved.
(In reply to comment #91)
from Leland Lucius <email address hidden> 2011-04-01 00:48:46 EDT ---
>> <snip>
>> Why change several wxLogDebug() calls to wxLogMessage()? I would think that
>> type of info would only be clutter to most users, and relevant only to those of
>> us building Debug versions.
>>
> Did that because it was "hiding" what was going on when searching for the
> libraries. I felt they would assist with debugging problems when users
> complained about Audacity not finding the FFmpeg libraries. And since the
> users get Release versions, the messages wouldn't be available.
Yes, obviously I know that. Wanted to raise the issue because they formerly
were wxLogMessage() and a few months ago I changed them to wxLogDebug() because
I thought it was just cruft, and FFmpeg had been unchanged for a while. Nobody
complained, so I thought that was justified.
I think the only reason to show them in release versions is if we are actually
still getting FFmpeg errors -- but as we're using a new FFmpeg, I think yes,
leave them in at least for this release.
>
> Maybe I'm misunderstanding the reason for the log. What information in there
> does the user any good? Isn't it more for the folks that are assisting users
> with problems?
It's useful for debugging, too. :-)
And some wxLogDebug() calls are good to leave in, although probably many should
be commented out when the debugging is completed.
>
>> I see these changes are not backward compatible, but if Gale's okay with that
>> for users, I say commit this patch.
>
> How far back do you want it to go?
I wasn't advocating for *any* backward compatibility, personally. Just wanted
to double check with Gale because I said commit the patch, but that question
had not been resolved.