reset Preferences CFG file

[Gale Andrews]

It makes resetting easier, it doesn't eliminate all the problems.

I agree, because you may not be able to launch Audacity.

"I reinstalled Audacity but the problem continued."

People already know how to reset Audacity.

Well some do, but I think many wrongly assume that reinstalling will reset prefs without them having to notice and enable the "Reset Preferences" box. That's another reason I think a separate reset app would be useful as well as a method within Audacity.

Not too far back one of the Developers went through and made sure that most, if not all, of the preference Writes were immediately flushed.

It was your friend Vaughan.

Does this mean Ed that when you do your reset from Prefs, you don't force restart of Audacity?


Gale

[Gale Andrews]

I think the Load/Save should be kept out of the proposal for now, which is complex enough when you get down to the details.

I would feel it much cleaner to force restart of Audacity if you Reset Preferences within Audacity. Are you sure Ed, you have covered everything in Prefs that requires restart, like the different effect formats? What about the Audacity temp directory? If that was set to non-default in the session, then the user resets prefs, Audacity can't change that directory to default in that session.

Regarding "NewPrefsInitialized=1", the current code deletes it when Audacity is launched, so it does no harm. I would be inclinded to think we probably should write "NewPrefsInitialized=1" rather than delete .cfg, in case the user goes back to 2.0.6 or previous (quite possible if they are having problems). Otherwise, they won't be guaranteed to get their reset.

I think "Reset Preferences" should be only that if it's initiated from the Prefs dialogue - it should not go changing EQ presets, Custom FFmpeg presets, Chains or anything else not activated by resetting .cfg. Reset Preferences is already more drastic than it used to be - it will request rescan all effects AFAICT, not just VST.

There "may" be a case for trashing the Audacity folder for application data and installing a new .cfg file containing "NewPrefsInitialized=1", but I feel that should be presented as more than "Reset Preferences".


Gale

[Edgar]

Does this mean Ed that when you do your reset from Prefs, you don't force restart of Audacity?

How I currently do it is to not have the reset done until Audacity exits. Other options exist, as I said before, the configuration class has very good tools for this sort of thing and, as long as no preference value is cached globally, anything you design should work just fine.

[waxcylinder]

... "I reinstalled Audacity but the problem continued."

People already know how to reset Audacity.

Some do some don't, I usually forget where the .cfg file is stored and have to go back to the Manual to look up the procedure.

But the big problem I found when user my "documentation user" account: no admin privileges, Windows standard defaults hidden folders/files hidden no file extensions shown i.e. a "civilian" Windows user.

The problem here is the instructions in the current Manual (and previous) just don't work for a civilian user as they can't see the appdata folders where Audacity stores the .cfg file. So the instructions make no sense (fooled me this time for a little while ) - which is why I kicked off the recent -quality thread and have been working on enhancing the proposal: http://wiki.audacityteam.org/wiki/Propo ... _cfg_Reset

David Bailes taught me a cute trick workaround which is to type %appdata% in the Windows Explorer address bar - and we plan to add that tip to the Manual's reset advice.

But that is really a stopgap in my view - too "techy" for a lot of our users (judging by posts on this Forum).

Peter.

[waxcylinder]

I think the Load/Save should be kept out of the proposal for now, which is complex enough when you get down to the details.

+1

I would feel it much cleaner to force restart of Audacity if you Reset Preferences within Audacity.

I don't see why that would be necessary - except that if you did a full "factory reset" your toolbars would all jump around back to default positions and sizes. Would we offer an "Undo" or would this be a one-way ticket?

There "may" be a case for trashing the Audacity folder for application data and installing a new .cfg file containing "NewPrefsInitialized=1", but I feel that should be presented as more than "Reset Preferences".

A case for this is that just resetting Preferences would not reset the Toolbars, which sometimes needs to be done.

Peter

[waxcylinder]

David Bailes taught me a cute trick workaround which is to type %appdata% in the Windows Explorer address bar - and we plan to add that tip to the Manual's reset advice.

Done.

[Gale Andrews]

Does this mean Ed that when you do your reset from Prefs, you don't force restart of Audacity?

How I currently do it is to not have the reset done until Audacity exits. Other options exist, as I said before, the configuration class has very good tools for this sort of thing and, as long as no preference value is cached globally, anything you design should work just fine.

I feel that Windows users especially are used to not having changes happen before restarting applications. So given force restart is a bit harsh, you could just schedule the adjustment of audacity.cfg after exit.

Did you test using a non-default temp directory, then resetting prefs without restart? I would be surprised if that did not cause problems if it is really changing the temp directory to default mid-session.


Gale

[Gale Andrews]

the big problem I found when user my "documentation user" account: no admin privileges, Windows standard defaults hidden folders/files hidden no file extensions shown i.e. a "civilian" Windows user.

That default is the same for admin users too.

The problem here is the instructions in the current Manual (and previous) just don't work for a civilian user as they can't see the appdata folders where Audacity stores the .cfg file.So the instructions make no sense (fooled me this time for a little while )

Sorry but I have to disagree that the instructions make no sense. The instructions are correct if you follow the steps for your version of Windows to show hidden files and folders. Once you make the change and close the "Folder Options" box, if you have Users/<your username> selected in the tree, then AppData will appear immediately in the window. The tree won't update until you restart Explorer. That is the only mistake that I can guess you might have been making.

But that is really a stopgap in my view - too "techy" for a lot of our users (judging by posts on this Forum).

There is nothing techy about running the Audacity for Windows installer, if users are not able to manipulate Explorer.


Gale

[steve]

in case the user goes back to 2.0.6 or previous

I feel that I must complain about this negative design philosophy (which has come up many time previously).

If we're always thinking, "oh, but what if the user wants to go back to an obsolete version of Audacity?"
Well that is their choice, not our choice. If they go back to an obsolete version then they get the bugs and limitations of that version.
Certainly Audacity should not obstruct the user's choice to use an obsolete version, but purposefully designing in a downgrade path will almost always require extra code that has no benefit to current or future users - as far as the current and future code is concerned it is "junk". With that additional code comes additional risk of bugs, and additional maintenance until such time that it is removed.

If the user wants to go back to an obsolete version, then all they need to do is to uninstall Audacity and reinstall the obsolete version. If they wish to ensure that they have old settings, or old versions of stuff, they should restore their backups. If they don't have backups, that was their choice. "Backups" are not a novel concept, everyone knows about backups even if most choose not to make them.

Taking the current example of resetting preferences:
If the user goes back to Audacity 2.0.6 or earlier, and they have previously had Audacity 1.2.x installed. Audacity 2.0.6 and earlier read the preferences from Audacity 1.2.x. The steps to reset preferences for Audacity 2.0.6 are documented in the 2.0.6 documentation, so if they go back to Audacity 2.0.6 or earlier and want to reset preferences then they will need to reset preferences according to the 2.0.6 documentation, which for Windows is to select "Reset Preferences" on install.

I agree that if the user resets preferences for Audacity 2.0.7 or later, and then uninstalls that version and installs 2.0.6 or earlier, then it is not obvious that they will then inherit settings from 1.2.x (if they had it previously installed on that machine and the registry keys still exist). However, that is their choice - Audacity 2.0.6 and earlier inherit settings from 1.2.x - it's a "feature" of that version. If they don't want that feature they should either not downgrade their version of Audacity, or they should deal with it according to the documentation for that version.

Saying that this is a problem acknowledges that the negative design philosophy that gave us that "feature" introduces problems in the future. In my opinion, Audacity 2.0 should have had a clean break from the 1.x versions and NOT read the 1.2.x preferences. It is precisely because of this negative design philosophy that we now need to consider 1.2.x settings.

In my opinion it is MUCH better that effort goes into making future versions of Audacity better and leave obsolete versions in the past where they belong. We have finally cut ties with 1.2.x legacy and I strongly oppose reintroducing that burden. In 10 years time I don't want to be thinking "oh, what about if a user wants to go back to Audacity 1.2.6?" or "what about the 1.2.6 preferences?" When Audacity 2.0.7 is released I will be relieved that there is no longer a need to work around 1.2.x.

[Gale Andrews]

David Bailes taught me a cute trick workaround which is to type %appdata% in the Windows Explorer address bar - and we plan to add that tip to the Manual's reset advice.

Done.

I have tested on XP and it works the same on that.

What you say in the Manual:

Depending on your privileges you may not have visible access to the AppData folder

is (or should be) extremely unlikely to happen.

Standard users or even guests that set Folder Options to show hidden files/folders can see or access hidden files and folders in their own account, even if the admin has chosen to hide hidden files/folders when logged into their account.

The only way an admin can stop standard users or guests from seeing hidden files and folders in their own accounts is to a) hack the registry to remove that option from Folder Options (which will then affect the admin as well) or b) remove permissions on specific folders from all but the administrator account (in the "Security" tab of the folder properties).

Have you done b)? If not, are you seeing lock symbols or receiving permission errors as the standard user? In that case the permissions have broken of their own accord (which does happen).


Gale