reset Preferences CFG file

[Gale Andrews]

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).

Steve, we're talking specifically about the best way of resetting the .cfg file here. I wasn't making a general plea for backward (let alone forward) compatibility even though yes I err to considering that at least backward compatibility is important.

I'm also thinking that if as an interim measure we do post small apps on the Forum to let users reset .cfg for Mac and Windows, not all users will have 2.0.7 (definitely the case now).

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).

Yes, exactly (and in most cases the registry keys would still exist). What is the harm that "NewPrefsInitialized=1" does to the current code?

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.

Obviously, I strongly disagree on that specific. For example, there would have been upgraders from 1.2.x that would find they could no longer export MP3 without relocating LAME. The result? They'd have gone back to 1.2.


Gale

[Gale Andrews]

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.

As I see it happening... If you run 2.0.6 (even at default settings), then run 2.0.7, the toolbars are not in the default 2.0.7 order. View > Toolbars > Reset Toolbars does not correct toolbars to the default 2.0.7 order, but I think this is because the 2.0.6 default window width is insufficient to do so. Just drag the window wider, and the order should be as per 2.0.7.

If you delete .cfg then run 2.0.7, you get the default 2.0.7 window width and toolbar order (at least I do). So I don't understand why you say that resetting Preferences would not reset the toolbars. Reset and restart (in Ed's patch) should also give you default window width and toolbar order, but if not, trashing Audacity's app data folder is not likely to make any difference.


Gale

[steve]

Steve, we're talking specifically about the best way of resetting the .cfg file here.

Yes, and you are basing your suggestion on the possibility of users upgrading to the new version, then downgrading to an obsolete version, and running into problems with the old version and expecting that resetting preferences in the new version will have fixed the problem in the old version. My objection is relevant.

I wasn't making a general plea for backward (let alone forward) compatibility

I know - Backward compatibility is about a new version supporting data created in an older version. Forward compatibility is about anticipating the requirements of future versions. Your plea is about loss aversion.

I err to considering that at least backward compatibility is important.

It has nothing to do with backward compatibility. Ensuring that old preferences don't break the new version is about backward compatibility. Ensuring that old projects can be opened in the new version is backward compatibility. Worrying about whether new projects will open in obsolete versions of Audacity is a status quo bias that inhibits progress by demanding forward compatibility retrospectively. In other words, because Audacity 1.2.x was not forwardly compatible with Audacity 2.0.6, we now need to retrospectively work around that incompatibility in developing Audacity 2.0.7 and carry that burden into future versions.

there would have been upgraders from 1.2.x that would find they could no longer export MP3 without relocating LAME. The result? They'd have gone back to 1.2.

Red herring.

[waxcylinder]

So I don't understand why you say that resetting Preferences would not reset the toolbars.

Because if you read the Proposal one if the original (and still existing ideas) is to implement Preferences reset through Edit>Preferences with each pane having a Reset button (which could wither reset the Prefs on that pane or all Prefs - the proposal was/is ambiguous). There is nothing in Edit>Preferences to reset Toolbars - hence my extension of James' idea of having a new "Reset" pane in Preferences enabling the user to choose any or all and to include a Toolbars reset.

Of course if we implement a sledgehammer "factory reset" with an app or whatever then of course the toolbars get reset - that's exactly what I've been doing to document the Meter Toolbar page.

Personally I'd like to see both tools, something with a bit of delicacy and finesse - plus a sledgehammer.

Peter.

[Gale Andrews]

Steve, we're talking specifically about the best way of resetting the .cfg file here.

Yes, and you are basing your suggestion on the possibility of users upgrading to the new version, then downgrading to an obsolete version, and running into problems with the old version and expecting that resetting preferences in the new version will have fixed the problem in the old version. My objection is relevant.

So is my objection relevant. Consider if user has a problem that they can't launch Audacity until they do a complete reset of .cfg. With your plan, if they go back to the old version (perhaps they have not downgraded but still have it), and they ever had 1.2, then they still can't launch Audacity. Average impatient user's reaction - write to [email protected] with expletives or give up on Audacity altogether.

If "NewPrefsInitialized=1" harmed current Audacity, or required work to mean that it didn't harm it, then yes I would agree with you.

there would have been upgraders from 1.2.x that would find they could no longer export MP3 without relocating LAME. The result? They'd have gone back to 1.2.

Red herring.

Sorry Steve, no. Get your TIme Machine out and see what would have happened.


Gale

[Gale Andrews]

So I don't understand why you say that resetting Preferences would not reset the toolbars.

Because if you read the Proposal one if the original (and still existing ideas) is to implement Preferences reset through Edit>Preferences with each pane having a Reset button (which could wither reset the Prefs on that pane or all Prefs - the proposal was/is ambiguous).

Do you support that idea, if it's ambiguous? I'm -1. I think that idea is complex and could limit the chance of acceptance. I can only see it working if each pane had two buttons, one to reset that Pane's prefs, and a button to reset all Prefs (however defined).

There is nothing in Edit>Preferences to reset Toolbars - hence my extension of James' idea of having a new "Reset" pane in Preferences enabling the user to choose any or all and to include a Toolbars reset.

So is your proposal to move View > Toolbars into Preferences? Or to add a "Reset Toolbars" button into every Preferences pane? That would mean three buttons if we had a choice to reset just an individual preferences pane. I don't see the point of a "Reset Toolbars" button because I think Prefs should have a "sledgehammer" button.

Or would you want to empty audacity.cfg after Audacity quits, but preserve the toolbar and other settings not listed in Preferences, so that nothing except items listed in the Preferences GUI get reset? I can see the case for that. Perhaps the button would say "Defaults"? But as a "problem fixer" that may not be effective, given there are items in .cfg that are not in Prefs, and the trend is to add more of those.

Personally I'd like to see both tools, something with a bit of delicacy and finesse - plus a sledgehammer.

There has to be the sledgehammer (outside the Audacity GUI) for the case when Audacity won't launch. And I think for ease of access there should be a sledgehammer button in Audacity.


Gale

[steve]

Consider if user has a problem that they can't launch Audacity until they do a complete reset of .cfg

The likely outcome is that Audacity 2.0.7 then launches and that's the end of the story.

With your plan, if they go back to the old version (perhaps they have not downgraded but still have it), and they ever had 1.2, then they still can't launch Audacity.

Why not? Did they have a problem that they were unable to launch their old version before they installed Audacity 2.0.7 and is it that same problem that prevents Audacity 2.0.7 from launching? If so, then 2.0.7 would never have been launched and any reset button in Audacity 2.0.7 would be unavailable.

Only if we have an external application to reset preferences, or an option in the installer to reset preferences (as we have in 2.0.6) would the user be able to reset preferences for 2.0.7. Why would a user choose to use the Audacity 2.0.7 preference reset, rather than the Audacity 2.0.6 preference reset, if they have never run Audacity 2.0.7 and they want to reset preferences for Audacity 2.0.6?

If the user still has an old 2.x version installed and have 2.0.7 installed, then that is a non-standard installation so we can assume that the user is not completely clueless.

If "NewPrefsInitialized=1" harmed current Audacity, or required work to mean that it didn't harm it, then yes I would agree with you.

Take a different scenario:
A happy user of Audacity since 1.2.6. They set up their preferences in 2009 and have lived happily with them since that time.
They upgrade to 2.0.7, but run into a bug so they want to go back to 2.0.6 until the bug is resolved. However, before they gave up on 2.0.7 they reset preferences.
If we simply delete the cfg file, then 2.0.7 gets fresh preferences, but if they go back to 2.0.6 they get their old preferences, inherited from their old 1.2.6 settings.
If we include "NewPrefsInitialized=1", then 2.0.7 gets fresh preferences, but if they go back to 2.0.6 they have lost those settings as well, and no obvious way to get their old 1.2.6 preferences back.

Get your TIme Machine out and see what would have happened.

I'd love to, but doesn't the burden of proof lie with the party making the assertion?

[Gale Andrews]

I err to considering that at least backward compatibility is important.

It has nothing to do with backward compatibility. Ensuring that old preferences don't break the new version is about backward compatibility. Ensuring that old projects can be opened in the new version is backward compatibility.

Are you opposed to those things?

Worrying about whether new projects will open in obsolete versions of Audacity is a status quo bias that inhibits progress by demanding forward compatibility retrospectively.

Yes if possible I like that but I have understood the message that it's often impractical. I don't see the direct relevance to the issue at hand. As I said, please enlighten me as to the harm that "NewPrefsInitialized=1" does to 2.0.7.

In other words, because Audacity 1.2.x was not forwardly compatible with Audacity 2.0.6, we now need to retrospectively work around that incompatibility in developing Audacity 2.0.7 and carry that burden into future versions.

What is that burden, given 2.0.7 does not recognise 1.2 settings?

Gale

[Gale Andrews]

Consider if user has a problem that they can't launch Audacity until they do a complete reset of .cfg

The likely outcome is that Audacity 2.0.7 then launches and that's the end of the story.

Yes but that isn't how users think, much of the time. How often do we see it on this very Forum
"It didn't work so I went back to the older version."

With your plan, if they go back to the old version (perhaps they have not downgraded but still have it), and they ever had 1.2, then they still can't launch Audacity.

Why not? Did they have a problem that they were unable to launch their old version before they installed Audacity 2.0.7 and is it that same problem that prevents Audacity 2.0.7 from launching? If so, then 2.0.7 would never have been launched and any reset button in Audacity 2.0.7 would be unavailable.

No, the scenario is that they have some problem that requires a clean reset of .cfg which is not resolved by merely deleting .cfg if they go back to 2.0.6 which reads the old 1.2 preferences.

Why would a user choose to use the Audacity 2.0.7 preference reset, rather than the Audacity 2.0.6 preference reset, if they have never run Audacity 2.0.7 and they want to reset preferences for Audacity 2.0.6?

If they can't and could never start 2.0.7, they could merely delete .cfg then run 2.0.6.

They could have run 2.0.7 and hit some issue that doesn't stop it launching but could impair playback/or recording. Perhaps they were using 96000 Hz in 1.2 and 2.0.6 but their new device wants 44100 Hz (or 44100 Hz if the system is 44100 Hz).

If "NewPrefsInitialized=1" harmed current Audacity, or required work to mean that it didn't harm it, then yes I would agree with you.

Take a different scenario:
A happy user of Audacity since 1.2.6. They set up their preferences in 2009 and have lived happily with them since that time.
They upgrade to 2.0.7, but run into a bug so they want to go back to 2.0.6 until the bug is resolved. However, before they gave up on 2.0.7 they reset preferences.
If we simply delete the cfg file, then 2.0.7 gets fresh preferences, but if they go back to 2.0.6 they get their old preferences, inherited from their old 1.2.6 settings.
If we include "NewPrefsInitialized=1", then 2.0.7 gets fresh preferences, but if they go back to 2.0.6 they have lost those settings as well, and no obvious way to get their old 1.2.6 preferences back.

Um, well a reset is a reset, the purpose of which is to go back to factory prefs for that version of Audacity in an attempt to solve a problem. That's the purpose of reset in 2.0.7 and it was the purpose of reset in 2.0.6. They can't have it both ways.

doesn't the burden of proof lie with the party making the assertion?

I agree, but you haven't proved why "NewPrefsInitialized=1" harms 2.0.7+. I'm not convinced by the case that a user wanted a reset to factory fresh but not to go back to factory fresh.


Gale

[steve]

Ensuring that old preferences don't break the new version is about backward compatibility. Ensuring that old projects can be opened in the new version is backward compatibility.

Are you opposed to those things?

Not at all. Where backward compatibility can be maintained without crippling new development I think it is a good thing.
I also think that forward compatibility is a good thing, though harder to achieve as future requirements are often not known, but we can sometimes anticipate what future requirements are likely to be, and allow for that in design decisions.

As I said, please enlighten me as to the harm that "NewPrefsInitialized=1" does to 2.0.7.

An example already given. A user may want to reset preferences for Audacity 2.0.7 but not wipe out their old 1.2.x preferences from 2.0.6.

What is that burden, given 2.0.7 does not recognise 1.2 settings?

The burden is that we have to continue supporting a feature that is no longer in Audacity.

Currently, the first time this version of Audacity is run Audacity tries to migrate old preferences (if they exist) but if the entry "NewPrefsInitialized" is found, Audacity deletes it. So by creating a new cfg file and writing "NewPrefsInitialized=1" to it, we are writing a line that will be immediately deleted on launch. My point is, why are we yet again placing so much importance on maintaining the status quo?