Slow Gatekeeper Bug

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

Slow Gatekeeper Bug

James Crook
I am thinking that the slow-gatekeeper bug should be added to Bugzilla
as a new bug with a new title.  It is related to 1567, but not the
same.  Gale, what is your thinking?

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper Bug

Gale
Administrator
On 29 January 2017 at 14:29, James Crook <[hidden email]> wrote:
> I am thinking that the slow-gatekeeper bug should be added to Bugzilla
> as a new bug with a new title.  It is related to 1567, but not the
> same.  Gale, what is your thinking?

I totally agree it should be a new bug.

I was dissuaded from adding it because you (James) seemed to suggest
it was an expected limitation. But when I tested other apps that have
Developer-ID codesigning, even on my machine, they don't have the
"damaged" problem, so I think it really is an Audacity insufficient
response to a Sierra bug. I gave a full report on this - I would have
to look it up.

Yes it's a new bug because it occurs on 10.12.0 too, which 1567 doesn't
occur on.

I added this already to
http://wiki.audacityteam.org/wiki/Partial_Support_for_Mac_Sierra_in_2.1.3

which you did not seem to disagree with, but doing so might imply a P1 rating.
I think it is P1/P2 borderline.

Would it be reasonable to enter it now as P2 then promote it to P1 after 2.1.3?
It may have to be demoted again, or may be reasonable to do so if few people
report it, but I think we should at least have a go at fixing this
after 2.1.3 is out.


Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper Bug

James Crook
On 1/29/2017 5:49 PM, Gale Andrews wrote:

> On 29 January 2017 at 14:29, James Crook <[hidden email]> wrote:
>> I am thinking that the slow-gatekeeper bug should be added to Bugzilla
>> as a new bug with a new title.  It is related to 1567, but not the
>> same.  Gale, what is your thinking?
> I totally agree it should be a new bug.
>
> I was dissuaded from adding it because you (James) seemed to suggest
> it was an expected limitation. But when I tested other apps that have
> Developer-ID codesigning, even on my machine, they don't have the
> "damaged" problem, so I think it really is an Audacity insufficient
> response to a Sierra bug. I gave a full report on this - I would have
> to look it up.

I'm even OK with it being two extra bugs (I think it probably is)...
1. That the gatekeeper is slow
2. That gatekeeper reports 'damaged'.

Item 2, 'Damaged' is or could be correct Gatekeeper behaviour, since we
have session files within the .app.  It could be that Apple now disallow
that, and we just either haven't read the documentation properly, or
have not set up plist in such a way as to explicitly allow it.  My
thinking is that gatekeeper may be seeing a change by guest to a file
authorised by admin as suspicious....

In fact 1567 (aside from the effect on Nyquist) could be legitimate,
since loading an unsigned LAME plug-in into a signed Audacity is surely
a security hole?  So I would have been less surprised by 1567 if it
happened all the time.  What is the ownership of your LAME plugin?  Is
it the same as Audacity (i.e. admin)?

So in a certain sense '2' is an 'expected' change.
But 1 isn't.
It suggests you have a slow internet, or that for some reason Gatekeeper
is checking a very large number of possible files.



> Yes it's a new bug because it occurs on 10.12.0 too, which 1567 doesn't
> occur on.
>
> I added this already to
> http://wiki.audacityteam.org/wiki/Partial_Support_for_Mac_Sierra_in_2.1.3
Yes, I saw that, and that is what prompted me to ask.
> which you did not seem to disagree with, but doing so might imply a P1 rating.
> I think it is P1/P2 borderline.
If you want to rate it P1, that is fine.

> Would it be reasonable to enter it now as P2 then promote it to P1 after 2.1.3?
No, I don't think so.  We have a dispensation to release with P1's on
Mac Sierra (not just on 10.12.2+), so there is no reason to artificially
demote it 'to allow release'.
If it affects Mac El Capitan, then we do need to consider very carefully
whether it is P1 or P2.

> It may have to be demoted again, or may be reasonable to do so if few people
> report it, but I think we should at least have a go at fixing this
> after 2.1.3 is out.
I think it very unlikely we can do anything about 'slow gatekeeper'.  We
probably can prevent the 'damaged' outcome by not having session data
within the app.  If you want to lobby me that we should try that right
now, even though we have the dispensation to release with Sierra P1s, I
will certainly consider that.


--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper Bug

Gale
Administrator
On 29 January 2017 at 18:58, James Crook <[hidden email]> wrote:

> On 1/29/2017 5:49 PM, Gale Andrews wrote:
>> On 29 January 2017 at 14:29, James Crook <[hidden email]> wrote:
>>> I am thinking that the slow-gatekeeper bug should be added to Bugzilla
>>> as a new bug with a new title.  It is related to 1567, but not the
>>> same.  Gale, what is your thinking?
>> I totally agree it should be a new bug.
>>
>> I was dissuaded from adding it because you (James) seemed to suggest
>> it was an expected limitation. But when I tested other apps that have
>> Developer-ID codesigning, even on my machine, they don't have the
>> "damaged" problem, so I think it really is an Audacity insufficient
>> response to a Sierra bug. I gave a full report on this - I would have
>> to look it up.
>
> I'm even OK with it being two extra bugs (I think it probably is)...
> 1. That the gatekeeper is slow

Some other apps show that slow verification too, and it occurs even
if the same user installs and runs Audacity. So yes it is probably
separate but it becomes a liability if different users install and run
Audacity because then you may have to wait for that long verification
at every Audacity launch, even if you don't get "damaged".


> 2. That gatekeeper reports 'damaged'.
>
> Item 2, 'Damaged' is or could be correct Gatekeeper behaviour, since we
> have session files within the .app.  It could be that Apple now disallow
> that, and we just either haven't read the documentation properly, or
> have not set up plist in such a way as to explicitly allow it.  My
> thinking is that gatekeeper may be seeing a change by guest to a file
> authorised by admin as suspicious....

Reading again what I reported on jc10, I think we should wait to
test jc11 before entering the new bug or bugs. It looked as if the
predefined Portable Settings folder was making the verification
and severity of warning worse.

It's possible that the "damaged" bug may only exist in jc11 if the user
adds their own Portable Settings folder, or only if the user who installed
Audacity and the user who runs it are different.

Probably it would be good in any case to add the warning you
suggested to the Manual about the need for the Portable Settings
folder to have 777 permissions.


> In fact 1567 (aside from the effect on Nyquist) could be legitimate,
> since loading an unsigned LAME plug-in into a signed Audacity is surely
> a security hole?  So I would have been less surprised by 1567 if it
> happened all the time.  What is the ownership of your LAME plugin?  Is
> it the same as Audacity (i.e. admin)?

If that became the case Audacity would probably become unusable
because user-added plugins would be disallowed too.

The "gale" user is owner of libmp3lame.dylib and the group is staff.


> So in a certain sense '2' is an 'expected' change.

Please remind me why codesigned Audacity shows

spctl --assess -v /Applications/Audacity.app
/Applications/Audacity.app: a sealed resource is missing or invalid


> But 1 isn't.
> It suggests you have a slow internet, or that for some reason Gatekeeper
> is checking a very large number of possible files.

The internet isn't that slow (25 Mbps).


>> Yes it's a new bug because it occurs on 10.12.0 too, which 1567 doesn't
>> occur on.
>>
>> I added this already to
>> http://wiki.audacityteam.org/wiki/Partial_Support_for_Mac_Sierra_in_2.1.3
> Yes, I saw that, and that is what prompted me to ask.

>> which you did not seem to disagree with, but doing so might imply a P1 rating.
>> I think it is P1/P2 borderline.
> If you want to rate it P1, that is fine.
>
>> Would it be reasonable to enter it now as P2 then promote it to P1 after 2.1.3?
> No, I don't think so.  We have a dispensation to release with P1's on
> Mac Sierra (not just on 10.12.2+), so there is no reason to artificially
> demote it 'to allow release'.

OK. 1567 was mostly discussed in the vote but the wording does
give dispensation for Sierra bugs plural. But as above I will wait to
see what behaviour jc11 shows on my machine.


> If it affects Mac El Capitan, then we do need to consider very carefully
> whether it is P1 or P2.

I'd have to reinstall El Capitan to test that on my machine, but
no-one else has seen this "damaged" problem yet. We can ask
users to test this in RC1.

Paul mentioned recording dropouts caused by Sierra but I don't
have enough information to judge that. It could be our buffer
setting or it could be the recording device does not support Sierra
or user has not updated its drivers/firmware for Sierra.

There is an El Capitan bug with Mac launchservices that means
Audacity does not launch. It only affects a few machines, AFAIK.
It is not on Bugzilla yet. I want to add it to our FAQ about launch
issues, as well as put it on Bugzilla.


>> It may have to be demoted again, or may be reasonable to do so if few people
>> report it, but I think we should at least have a go at fixing this
>> after 2.1.3 is out.
> I think it very unlikely we can do anything about 'slow gatekeeper'.  We
> probably can prevent the 'damaged' outcome by not having session data
> within the app.  If you want to lobby me that we should try that right
> now, even though we have the dispensation to release with Sierra P1s, I
> will certainly consider that.

We're going to to do that anyway now aren't we - don't have Portable
Settings inside the app?



Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Slow Gatekeeper Bug

James Crook
On 1/29/2017 9:09 PM, Gale Andrews wrote:
> Please remind me why codesigned Audacity shows
> spctl --assess -v /Applications/Audacity.app
> /Applications/Audacity.app: a sealed resource is missing or invalid
Was that newly downloaded or after having run and having created session
files (or even damaged)?

For me (on El Capitan) it gives
/Applications/Audacity.app: accepted
source=Developer ID

What does codesign -dv --verbose=4 /Applications/Audacity.app give?


This message
https://discussions.apple.com/thread/7615151?start=0&tstart=0
at the very least suggests that spctl --assess is not reliable...

>> I think it very unlikely we can do anything about 'slow gatekeeper'.  We
>> probably can prevent the 'damaged' outcome by not having session data
>> within the app.  If you want to lobby me that we should try that right
>> now, even though we have the dispensation to release with Sierra P1s, I
>> will certainly consider that.
> We're going to to do that anyway now aren't we - don't have Portable
> Settings inside the app?
What I am going to do 'anyway' is not create a portable settings directory.

If the portable settings directory is created by the user, then Audacity
WILL use paths inside the app, i.e. in that folder, including for
session data, but in that case the user will have already messed with
the app by creating the portable settings in it...   Portable Settings
might perhaps be more usable if session data went outside.  I don't
know.  At this point I don't think it is important enough to experiment
and find out, particularly as we agree that we ship 2.1.3 without
portable settings directory.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Remembering Save Directory ability lost.

Cliff Scott
Running Sierra 10.12.3.
Just built from master this evening. It seems as if somewhere along the line, before Jan 16, the remembering of the directory to save projects got lost.

1. Record a short passage.
2. Cmd/S to save and the default directory comes up as Documents.
3. Choose another save directory and save the project.
4. Quit Audacity.
5. Reopen Audacity and do another record the Cmd/S to save.
6. Documents again comes up as the place to save to.

With this build it NEVER remembers the save directory for a new recording. Not even in the same session. I know there was a discussion on this a short time ago, but I thought the issue was resolved. Apparently not. It remembers the "Open" directory and Export directory, but not the Save directory. My Dec 30 build remembers just fine.

Note: Open an existing project then it will come up with the correct directory for a "Save as", but do a new recording and it's back to Documents.

Cliff
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Paul Licameli
Cliff, do you understand how you can use git bisect to determine exactly when thus problem began?

PRL


On Sun, Jan 29, 2017 at 10:13 PM, Cliff Scott <[hidden email]> wrote:
Running Sierra 10.12.3.
Just built from master this evening. It seems as if somewhere along the line, before Jan 16, the remembering of the directory to save projects got lost.

1. Record a short passage.
2. Cmd/S to save and the default directory comes up as Documents.
3. Choose another save directory and save the project.
4. Quit Audacity.
5. Reopen Audacity and do another record the Cmd/S to save.
6. Documents again comes up as the place to save to.

With this build it NEVER remembers the save directory for a new recording. Not even in the same session. I know there was a discussion on this a short time ago, but I thought the issue was resolved. Apparently not. It remembers the "Open" directory and Export directory, but not the Save directory. My Dec 30 build remembers just fine.

Note: Open an existing project then it will come up with the correct directory for a "Save as", but do a new recording and it's back to Documents.

Cliff
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Cliff Scott
Sorry Paul, I'm afraid I don't have a clue. Very little experience with Git.

If you want to walk me through it off list I'll be glad to give it a go, but I know you're very busy.

Cliff
On Jan 29, 2017, at 9:45 PM, Paul Licameli <[hidden email]> wrote:

Cliff, do you understand how you can use git bisect to determine exactly when thus problem began?

PRL


On Sun, Jan 29, 2017 at 10:13 PM, Cliff Scott <[hidden email]> wrote:
Running Sierra 10.12.3.
Just built from master this evening. It seems as if somewhere along the line, before Jan 16, the remembering of the directory to save projects got lost.

1. Record a short passage.
2. Cmd/S to save and the default directory comes up as Documents.
3. Choose another save directory and save the project.
4. Quit Audacity.
5. Reopen Audacity and do another record the Cmd/S to save.
6. Documents again comes up as the place to save to.

With this build it NEVER remembers the save directory for a new recording. Not even in the same session. I know there was a discussion on this a short time ago, but I thought the issue was resolved. Apparently not. It remembers the "Open" directory and Export directory, but not the Save directory. My Dec 30 build remembers just fine.

Note: Open an existing project then it will come up with the correct directory for a "Save as", but do a new recording and it's back to Documents.

Cliff
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Peter Sampson-2
This is as a result of the change that was made by James as the
fix for Bug #1304:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1304

This issue is already logged in Enh #1305
http://bugzilla.audacityteam.org/show_bug.cgi?id=1305

During extensive testing and real-life usage I'm finding myself preferring
the new behavior with \Documents always being the default location
and not the last-used location.

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Cliff Scott
I
On Jan 30, 2017, at 9:32 AM, Peter Sampson <[hidden email]> wrote:

This is as a result of the change that was made by James as the
fix for Bug #1304:
http://bugzilla.audacityteam.org/show_bug.cgi?id=1304

This issue is already logged in Enh #1305
http://bugzilla.audacityteam.org/show_bug.cgi?id=1305

During extensive testing and real-life usage I'm finding myself preferring
the new behavior with \Documents always being the default location
and not the last-used location.

Looking the bug discussion I don't see anything regarding not being able to change the Save directory and have the change stick. The issue was to change the the default so the user could be sure to have rights to write to it. It's always been that once a directory change was done it was remembered, whether it was Audacity or the system I don't know, but it always worked.

I see where the Enh 1305 states that a save directory change is not remembered. I missed that when it happened.

I respectfully disagree with not being able to change the default Save directory. That is forcing people to either use what Audacity dictates or else change the directory with every save. We seem concerned that we don't do things that will cause users frustration, so why do we allow this? For what purpose is that being left this way for this release?. For me it would be great aggravation and I would be tempted to not use this version just because of the irritation. No other program that I know of forces the user like this.

Sorry for venting on this. For me it is a black eye to what otherwise is a really good version of Audacity. At least for me I can still use my Dec. 30 build and not have to deal with it, but others won't have that option.

Please reconsider the decision to postpone the fix to 2.1.4.

I won't lobby any more. Enough said from me.

Cliff


Peter.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

James Crook
Cliff,

I agree with you, and have pushed a fix:
https://github.com/audacity/audacity/commit/0cb89a895a25e4f1e7ca4045d0b95e786bce7ed2

This new code will be needed anyway when we address 1305 and 550, and
avoids a regression that would discourage users from upgrading.  I
considered doing enough to close 1305 and 550, but they are enhancements
and we are not agreed about exactly what the enhancements should be.  
Plus adding preferences to the preferences dialog WOULD delay us further.

--James.

On 1/30/2017 4:12 PM, Cliff Scott wrote:

> I
>> On Jan 30, 2017, at 9:32 AM, Peter Sampson <[hidden email]> wrote:
>>
>> This is as a result of the change that was made by James as the
>> fix for Bug #1304:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 <http://bugzilla.audacityteam.org/show_bug.cgi?id=1304>
>>
>> This issue is already logged in Enh #1305
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1305 <http://bugzilla.audacityteam.org/show_bug.cgi?id=1305>
>>
>> During extensive testing and real-life usage I'm finding myself preferring
>> the new behavior with \Documents always being the default location
>> and not the last-used location.
> Looking the bug discussion I don't see anything regarding not being able to change the Save directory and have the change stick. The issue was to change the the default so the user could be sure to have rights to write to it. It's always been that once a directory change was done it was remembered, whether it was Audacity or the system I don't know, but it always worked.
>
> I see where the Enh 1305 states that a save directory change is not remembered. I missed that when it happened.
>
> I respectfully disagree with not being able to change the default Save directory. That is forcing people to either use what Audacity dictates or else change the directory with every save. We seem concerned that we don't do things that will cause users frustration, so why do we allow this? For what purpose is that being left this way for this release?. For me it would be great aggravation and I would be tempted to not use this version just because of the irritation. No other program that I know of forces the user like this.
>
> Sorry for venting on this. For me it is a black eye to what otherwise is a really good version of Audacity. At least for me I can still use my Dec. 30 build and not have to deal with it, but others won't have that option.
>
> Please reconsider the decision to postpone the fix to 2.1.4.
>
> I won't lobby any more. Enough said from me.
>
> Cliff
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Peter Sampson-2
d'oh - just as I was getting used to and enjoying the new way ...

But I agree, better to fix the regression and avert upgrade-avoiders ;-))

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Cliff Scott
In reply to this post by James Crook
Thank you James. I had the thought maybe for the enhancement on 2.1.4 that if there was a configuration option to "remember" or not. Just a check box in one of the config screens. That way if one would rather have it as Peter likes then it is just a check mark away.

Cliff

> On Jan 30, 2017, at 12:14 PM, James Crook <[hidden email]> wrote:
>
> Cliff,
>
> I agree with you, and have pushed a fix:
> https://github.com/audacity/audacity/commit/0cb89a895a25e4f1e7ca4045d0b95e786bce7ed2
>
> This new code will be needed anyway when we address 1305 and 550, and
> avoids a regression that would discourage users from upgrading.  I
> considered doing enough to close 1305 and 550, but they are enhancements
> and we are not agreed about exactly what the enhancements should be.  
> Plus adding preferences to the preferences dialog WOULD delay us further.
>
> --James.
>
> On 1/30/2017 4:12 PM, Cliff Scott wrote:
>> I
>>> On Jan 30, 2017, at 9:32 AM, Peter Sampson <[hidden email]> wrote:
>>>
>>> This is as a result of the change that was made by James as the
>>> fix for Bug #1304:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 <http://bugzilla.audacityteam.org/show_bug.cgi?id=1304>
>>>
>>> This issue is already logged in Enh #1305
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1305 <http://bugzilla.audacityteam.org/show_bug.cgi?id=1305>
>>>
>>> During extensive testing and real-life usage I'm finding myself preferring
>>> the new behavior with \Documents always being the default location
>>> and not the last-used location.
>> Looking the bug discussion I don't see anything regarding not being able to change the Save directory and have the change stick. The issue was to change the the default so the user could be sure to have rights to write to it. It's always been that once a directory change was done it was remembered, whether it was Audacity or the system I don't know, but it always worked.
>>
>> I see where the Enh 1305 states that a save directory change is not remembered. I missed that when it happened.
>>
>> I respectfully disagree with not being able to change the default Save directory. That is forcing people to either use what Audacity dictates or else change the directory with every save. We seem concerned that we don't do things that will cause users frustration, so why do we allow this? For what purpose is that being left this way for this release?. For me it would be great aggravation and I would be tempted to not use this version just because of the irritation. No other program that I know of forces the user like this.
>>
>> Sorry for venting on this. For me it is a black eye to what otherwise is a really good version of Audacity. At least for me I can still use my Dec. 30 build and not have to deal with it, but others won't have that option.
>>
>> Please reconsider the decision to postpone the fix to 2.1.4.
>>
>> I won't lobby any more. Enough said from me.
>>
>> Cliff
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Gale
Administrator
In reply to this post by Cliff Scott
Actually a few other Windows applications force a save path
somewhere in the user's own space. I'm glad someone else
finally agreed with me that was poor behaviour.

It was P2 to be made P1 for 2.1.4. The Release Note in 1305
did state clearly what the problem was:

* (Windows and Mac) '''Audacity no longer remembers changes
  to its Save Project path.'''  The new default of the user's
  Documents folder is offered at every save, even if your default
  path in previous Audacity was some other location.

I was never asking to fully fix 1305 or to fix 550 for 2.1.3, just to
fix the regression introduced by 1304. Lumping the problem with
1305 perhaps made that unclear, despite what I wrote on list.

I still think where a bug fix directly creates a new problem that
there is a good case, as here, to reopen the bug with changed
title that states the new problem.

If so, 1304 would have had the above release note.

I am glad James was persuaded to fix the regression.



Gale


On 30 January 2017 at 16:12, Cliff Scott <[hidden email]> wrote:

>
> On Jan 30, 2017, at 9:32 AM, Peter Sampson <[hidden email]>
> wrote:
>
> This is as a result of the change that was made by James as the
> fix for Bug #1304:
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1304
>
> This issue is already logged in Enh #1305
> http://bugzilla.audacityteam.org/show_bug.cgi?id=1305
>
> During extensive testing and real-life usage I'm finding myself preferring
> the new behavior with \Documents always being the default location
> and not the last-used location.
>
>
> Looking the bug discussion I don't see anything regarding not being able to
> change the Save directory and have the change stick. The issue was to change
> the the default so the user could be sure to have rights to write to it.
> It's always been that once a directory change was done it was remembered,
> whether it was Audacity or the system I don't know, but it always worked.
>
> I see where the Enh 1305 states that a save directory change is not
> remembered. I missed that when it happened.
>
> I respectfully disagree with not being able to change the default Save
> directory. That is forcing people to either use what Audacity dictates or
> else change the directory with every save. We seem concerned that we don't
> do things that will cause users frustration, so why do we allow this? For
> what purpose is that being left this way for this release?. For me it would
> be great aggravation and I would be tempted to not use this version just
> because of the irritation. No other program that I know of forces the user
> like this.
>
> Sorry for venting on this. For me it is a black eye to what otherwise is a
> really good version of Audacity. At least for me I can still use my Dec. 30
> build and not have to deal with it, but others won't have that option.
>
> Please reconsider the decision to postpone the fix to 2.1.4.
>
> I won't lobby any more. Enough said from me.
>
> Cliff
>
>
> Peter.
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org!
> http://sdm.link/slashdot_______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Peter Sampson-2
1)  Just tested this on W10 withlatest alpha with James' fix
 audacity-win-r0cb89a8-2.1.3-alpha-30-jan-17

And it remembers the previous location fine on the lattestr alpha when saving
the next time.  It even remebered it when I ran latest alpha, then run previous
alpha and wa always offered ...\Documents each time - and then retunrned to
latest alpha wher it remembered tha location used on the previous us of latest
alpha.


2) Export (and also Export Multiple) also appear to rember the last used location
and offer that.


3) I do have separate concerns with File>Open as it shows similar poor behaviour
similar to the behaviour we fixed in 1304 for Save - in that on intial use after an
install the default Open location is the system folder wher I installed the latest
alpha.  

Surely it would be better if this also offered ...\Documents as the initial default.

Subsequent File>Open usage does remeber tha last used location and offer
that.

Do we need to log this as a separate bug?

Should we alos be fixing this for consistency in 2.1.3?

Thanks,
Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Peter Sampson-2
Mac nightly not yet available for testing

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

James Crook
In reply to this post by Peter Sampson-2
Export/Import key bindings, Batch commands, MIDI, Labels, Open  too.
Unless Gale marks them as P1 not fixing for 2.1.3.  Agree they need tracking Peter.

There's a hidden decision to make too, as to whether to share the same path, or record paths for these separately, or (shudder) have that as an option.  Also whether we save and load from same path is also not a given....

--James.


On 1/30/2017 11:28 PM, Peter Sampson wrote:
1)  Just tested this on W10 withlatest alpha with James' fix
 audacity-win-r0cb89a8-2.1.3-alpha-30-jan-17

And it remembers the previous location fine on the lattestr alpha when
saving
the next time.  It even remebered it when I ran latest alpha, then run
previous
alpha and wa always offered ...\Documents each time - and then retunrned to
latest alpha wher it remembered tha location used on the previous us of
latest
alpha.


2) Export (and also Export Multiple) also appear to rember the last used
location
and offer that.


3) I do have separate concerns with File>Open as it shows similar poor
behaviour
similar to the behaviour we fixed in 1304 for Save - in that on intial use
after an
install the default Open location is the system folder wher I installed the
latest
alpha.

Surely it would be better if this also offered ...\Documents as the initial
default.

Subsequent File>Open usage does remeber tha last used location and offer
that.

Do we need to log this as a separate bug?

Should we alos be fixing this for consistency in 2.1.3?

Thanks,
Peter.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Gale
Administrator
On 30 January 2017 at 23:49, James Crook <[hidden email]> wrote:
> Export/Import key bindings, Batch commands, MIDI, Labels, Open  too.
> Unless Gale marks them as P1 not fixing for 2.1.3.  Agree they need tracking
> Peter.

We already have http://bugzilla.audacityteam.org/show_bug.cgi?id=1578
"TXT and XML exports are not to Documents and may require elevation
to save".

Chain commands save to the configuration directory so that is not a
problem unless we want to change it.

Export MIDI path is not a problem and does not need to be stored because
you can't export MIDI until you have imported a MIDI, and MIDI import sets
Export MIDI to the path the MIDI file came from. Or if you save a MIDI track
as a project, Export MIDI path gets set to the path the project came from.

So I think 1578 is complete as it stands. New tracking is need for defaults
for open/import locations. I would not rate it more than P3.


> There's a hidden decision to make too, as to whether to share the same path,
> or record paths for these separately, or (shudder) have that as an option.
> Also whether we save and load from same path is also not a given....

I think we should consider extended preferences at some stage. We
could reduce the default preferences set by moving some of the
current more esoteric preferences into extended preferences, then
the extended preferences make Audacity more useful by allowing more
configuration.

I think it may be good to have a stored path for for TXT/XML as
a group.


Gale
  .


> On 1/30/2017 11:28 PM, Peter Sampson wrote:
>
> 1)  Just tested this on W10 withlatest alpha with James' fix
>  audacity-win-r0cb89a8-2.1.3-alpha-30-jan-17
>
> And it remembers the previous location fine on the lattestr alpha when
> saving
> the next time.  It even remebered it when I ran latest alpha, then run
> previous
> alpha and wa always offered ...\Documents each time - and then retunrned to
> latest alpha wher it remembered tha location used on the previous us of
> latest
> alpha.
>
>
> 2) Export (and also Export Multiple) also appear to rember the last used
> location
> and offer that.
>
>
> 3) I do have separate concerns with File>Open as it shows similar poor
> behaviour
> similar to the behaviour we fixed in 1304 for Save - in that on intial use
> after an
> install the default Open location is the system folder wher I installed the
> latest
> alpha.
>
> Surely it would be better if this also offered ...\Documents as the initial
> default.
>
> Subsequent File>Open usage does remeber tha last used location and offer
> that.
>
> Do we need to log this as a separate bug?
>
> Should we alos be fixing this for consistency in 2.1.3?
>
> Thanks,
> Peter.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Gale
Administrator
In reply to this post by James Crook
Testing on Windows 10, there are still two behaviour "regressions"
versus 2.1.2:

* After you import a MIDI or text file into a project, further incoming
  audio or AUP files do not change the path the save project window
  opens to, as used to happen.

* Even though incoming audio/AUP files change the path the project
   save window opens to, the new path does not survive close project
   or exit, but reverts to Documents.

Presumably these are things that Windows "just saved", so to
avoid "annoyances", incoming audio/AUP files should I believe
trigger saving of the [SaveAs] path to audacity,cfg.

I suppose from where we are now, and given I think P2 would
suffice for these, they could go in the existing bug 1305. Its
release note will need to be modified anyway.

I have not tested on Mac yet.

One question follows - should incoming audio or AUP files also set
the Open/Import path?  I would think yes,



Gale


On 30 January 2017 at 18:14, James Crook <[hidden email]> wrote:

> Cliff,
>
> I agree with you, and have pushed a fix:
> https://github.com/audacity/audacity/commit/0cb89a895a25e4f1e7ca4045d0b95e786bce7ed2
>
> This new code will be needed anyway when we address 1305 and 550, and
> avoids a regression that would discourage users from upgrading.  I
> considered doing enough to close 1305 and 550, but they are enhancements
> and we are not agreed about exactly what the enhancements should be.
> Plus adding preferences to the preferences dialog WOULD delay us further.
>
> --James.
>
> On 1/30/2017 4:12 PM, Cliff Scott wrote:
>> I
>>> On Jan 30, 2017, at 9:32 AM, Peter Sampson <[hidden email]> wrote:
>>>
>>> This is as a result of the change that was made by James as the
>>> fix for Bug #1304:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1304 <http://bugzilla.audacityteam.org/show_bug.cgi?id=1304>
>>>
>>> This issue is already logged in Enh #1305
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1305 <http://bugzilla.audacityteam.org/show_bug.cgi?id=1305>
>>>
>>> During extensive testing and real-life usage I'm finding myself preferring
>>> the new behavior with \Documents always being the default location
>>> and not the last-used location.
>> Looking the bug discussion I don't see anything regarding not being able to change the Save directory and have the change stick. The issue was to change the the default so the user could be sure to have rights to write to it. It's always been that once a directory change was done it was remembered, whether it was Audacity or the system I don't know, but it always worked.
>>
>> I see where the Enh 1305 states that a save directory change is not remembered. I missed that when it happened.
>>
>> I respectfully disagree with not being able to change the default Save directory. That is forcing people to either use what Audacity dictates or else change the directory with every save. We seem concerned that we don't do things that will cause users frustration, so why do we allow this? For what purpose is that being left this way for this release?. For me it would be great aggravation and I would be tempted to not use this version just because of the irritation. No other program that I know of forces the user like this.
>>
>> Sorry for venting on this. For me it is a black eye to what otherwise is a really good version of Audacity. At least for me I can still use my Dec. 30 build and not have to deal with it, but others won't have that option.
>>
>> Please reconsider the decision to postpone the fix to 2.1.4.
>>
>> I won't lobby any more. Enough said from me.
>>
>> Cliff
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Remembering Save Directory ability lost.

Cliff Scott
In reply to this post by Peter Sampson-2
Peter,

Today's build on the Mac show the same symptoms on Open as you described.

Cliff

> On Jan 30, 2017, at 5:29 PM, Peter Sampson <[hidden email]> wrote:
>
> Mac nightly not yet available for testing
>
> Peter.
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
12
Loading...