Proposal Easy cfg Reset

From Audacity Wiki
Revision as of 06:08, 16 April 2011 by PeterSampson (Talk | contribs)

Jump to: navigation, search
Proposal pages help us get from feature requests into actual plans. This proposal page is about adding a "Reset Preferences" command to Audacity.
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.


  • Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.




Contents


The Problem

The audacity.cfg file can become corrupt leading to unexpected behaviours in Audacity that can only be fixed by "initializing" the contents of that file to NewPrefsInitialized=1. Trashing the file is not an option as Audacity may read previously-installed 1.2.x preferences and that preferences file may be corrupt. So the user must edit the audacity.cfg in a plain text editor and overwrite the file in its original location without changing the file extension. On Windows and Linux the user must show hidden files in order to open audacity.cfg.

Additionally:

  • VST plug-ins can stop Audacity starting properly, so a feature within Audacity, for example menu item or preferences reset-button might not work.
  • Display preferences can leave Audacity not appearing, i.e. underneath other windows, so again features to resolve this within Audacity might not be enough.


The Proposal

An easy way for users to reset the audacity.cfg file to a clean state - in effect setting the contents to "NewPrefsInitialized=1" or filling it with the default values that Audacity would use on first launch when it finds an audacity.cfg file that contains only "NewPrefsInitialized=1".


Developer/QA Backing

  • Peter 14Apr11: this was discussed earlier by QA folk on the Forum where there was almost unanimous support for this (with a couple of partial votes): Bill, Koz, Bruno, Peter, Ed 0.75, Steve 0.5 - see this forum thread: http://forum.audacityteam.org/viewtopic.php?f=20&t=55282&hilit=reset
  • Gale: +1. It has been discussed before that thread above as well.
  • James: +1 on a reset button.
    • Also +1 on making VST safer and +1 on safe-mode after an abnormal terminate or on special-launch.
  • Ed: +1 on the general concept (the +.75 was for the offered implementation)

Details

A "Reset Preferences" menu command

Where does it go in the menu structure and how does it behave? What warnings are given and how are they worded?

  • There is consensus that some warning at least should be given.
    • A UI Q&A site has some recommendations about 'are you sure' wording. The gist is to keep it short, be specific and label the buttons specifically, not just Yes/No.

Current suggested wording:

Title: Reset Audacity Preferences?
Reset Preferences?  
[Reset|Cancel]

We could have a hyperlink to online help. Specifically NOT local help in case the location for that is messed up. Hyperlink won't help if the user does not have a normal browser, but could help many users.

  • Bill: I prefer "Reset" over "Delete". It's what we're doing, and I believe most apps use that word.
    • +1. So do I. James 16:53, 14 April 2011 (UTC)
    • +1 Ed
    • +1 Peter

Alternative suggested wording:

Title: Reset Audacity Preferences?
Reset Audacity preferences to default values?
[Reset|Cancel] where Cancel is the default
  • James: A bit wordy? 'Audacity' becomes 'verbosity'? See the tip in the UX link.
    • Gale: I think a little "verbosity" could be needed until we have a help system or specific help button. Thinking about it, "Preferences" is a little misleading. Cfg covers more than what is exposed in the Preferences. "Restore default settings?"
    • James: Then for consistency we should change 'preferences' to 'settings' throughout.... to me there is not enough in it to make the change. Would having the help hyperlink I suggested be enough to mollify you over the shorter prompt?
      • Gale: Hyperlink and shorter text and not in its own pane are all OK for me.
      • Ed: +1 hyperlink. +1 "settings" over "preferences"

A "Reset" pane in Preferences

The avoids adding another menu command at the expense of a new prefs pane. What would this pane look like? What would it say and what steps would the user need to perform in order to reset preferences.

  • Gale: I think a Prefs pane would look pretty bare with just that. If we want more than an Edit menu button, then this Prefs pane could have e.g. save a copy of current .cfg. (and reload it), a bit like a "Theme" - could be e.g. a particular set of floated toolbars; or direct editing of .cfg.
    • James: Another option, we could put it on a general panel.

A "Reset" button in Preferences

Rds.png

Credits: Image by Ed

What Gets Reset?

  • Gale: I'm still concerned about the "settings" / "Preferences" distinction. I think the important extras in settings are open/export file paths, recent files and toolbars but those are going to be important to people. Even if the Prefs button said "Restore default settings", it's inside the Prefs so could easily be taken as only meaning what's in the Prefs window. I think my vote would go for an Edit menu item, maybe "Clear all settings" or similar unless the Prefs button text is much clearer. How about "Initialize .cfg" or "Initialize .cfg file" (with link)?
    • James: But we are also going to get people who don't want to lose some presets... Resetting preferences is pretty drastic, and really I think to solve the issue at hand we need to reset everything. We can't add a smart reset that just resets anything that might be a problem - though that is what we want if we could. Logically the preferences panel should contain ALL settings. We could add a panel with information such as '15 built in effects have user configured presets', 'default export path is...', '7 toolbars have user configured positions' and so on. Then preferences and settings are the same thing. I don't want to be explaining to users that preferences and settings are two different things.
    • Gale: There are possibly two different objectives. 1) "Return (currently listed) Prefs. to defaults" which is a quite common feature we don't have. 2) "Initialising the .cfg" which resets more settings and is needed to cure a corrupted Prefs file (or reset some setting that has created an issue). As I stated in bug 358, perhaps another issue we should consider is how the .cfg file gets "corrupted" and why/how this affects program behaviour. Should Audacity check the syntax of the .cfg contents and try and "repair" it? We know there are cases where user claims to have never even known about Preferences; yet initialising .cfg solves the problems.

      As for presenting to user, yes I quite like the idea of a panel that lists all the other current settings, whatever we decide about this Proposal. I still feel a high proportion of users will not realise the implications of initialising .cfg if we put our control in Preferences (however we label it and whatever Prefs contains). That's why I think initialisation is better done outside the interface (if that's possible). It also solves the "When?" problem (next section). There is an argument that doing this outside the interface might be less discoverable. However I don't feel many users will consider resetting preferences (in reality, initialising .cfg) as something likely to help. They are far more likely to pointlessly and repeatedly reinstall the app. So if we had a "repair.exe" they would I think discover that very easily and understand this might "start from scratch".


When Reset?

  • Gale: Will Audacity restart itself when this button is pressed or when Prefs is OK'ed? Also I wonder if a checkbox isn't better so you can see the current state (warning appears when you check the box)?
    • James: I don't know. It depends on who implements it.
    • Gale: This raises when do we reset? If we don't restart Audacity, that gives user the chance to change their mind if we have a checkbox (unless requesting the reset already resets the preferences in the dialogue, so that if you did not restart you would e.g. be warned about all actions again). I guess it's easier for user to understand if requesting reset does the Prefs reset at once?

Some kind of 'reset' before getting into Audacity

To handle the 'additionally' case (where the user might not successfully launch Audacity due to VST and other .cfg issues):

  • Googlable i.e. online help that explains how to delete the config/remove the problematic VSTs is a partial solution. It has to have the symptoms as far as a user is concerned', or they will not find the help. It should also explain what is going on.
    • Ed+1
  • If Audacity was exited unexpectedly, i.e. was started but was not closed properly, we could/should start in safe mode. That could mean disabling all plug ins, disabling simplified-audacity, using English language, default positioning and showing of toolbars and similar measures.
    • Gale: +1 but since this sounds as if there would be a dialog to inform the user, a dialogue with "safe" or "initialised" cfg options could also appear on CTRL + execute the app (or Option - execute on Mac). Maybe a command-line switch on Linux? If the interface solution is only to be basic we might be able to get by with just this "reset at launch".
  • Ed: A bit of work, but doable--we can have a separate script/app which cleans the 1.2 registry entries and/or initializes audacity.cfg (and if desired plugins.cfg). I vaguely understand how on Windows but know nothing of Mac & Linux!

Plug-in Safety

'Rogue' VST plug ins are a problem. It isn't the scanning for them that causes a problem, rather it is the loading of an incompatible DLL.

  • A framework with zillions of plug-ins, Eclipse, developed by IBM, has the concept of a textual 'manifest' that lists the plug-ins that the framework will load. If a plug-in crashes the framework, it is marked as don't load in the textual manifest.
  • Work is planned on a GUI plug-in framework for Audacity that will have exactly the same problem of rogue plug-ins. Audacity will create a manifest as a way to deal with this.
  • The effects menu can have an item 'more...' which only shows when additional VST plug-ins have been found (but not loaded). Clicking on 'more' could take the user to a dialog that allows them to review the found plug-ins and possibly load them all.
    • Gale: This looks mainly outside the terms of this proposal as worded. We do need a plug-in manager that lists the effects that are loaded/loadable and can selectively enable/disable them (or disable selected paths). But scanning is expensive for Audacity and user, so once scanned I think all plug-ins must be available by default. Manifest to block forbidden plug-ins sounds a good idea but blocked plug-ins should be marked in red in the user-accessible list (i.e. whose main data is plugins.cfg).
    • James: So I've added a new issue for it. If we need to discuss that issue we can do so here and later cut and paste to a new page if there is a lot in it. There is anyway likely to be a proposal page for GUI plug ins in due course so the more advanced extensions of plug-in management will go there, and probably subsume VST plug-in management and safety.


Discussion

  • James believes that we should address cases of fail-to-start actually within Audacity start up.
    • We should not be killed by dud VST plug-ins when not using them. We will need this kind of protection when we have other kinds of plug-ins too. In general we should not load plug-ins merely because they are there - so we should have a mechanism to show plug-in effects on the menu and delay loading the DLL until the effect is used. That's just one example.
  • Bill If Audacity starts and finds no, or an empty, plugins.cfg it will scan for VST effects, regardless of the setting of the "Rescan for VST effects" preference. This is convenient on first installation as Audacity will load all the user's VST effects. It's bad if Audacity chokes on a particular VST and crashes.
    • Gale: To clarify (well on Windows), if there is no or empty plugins.cfg and audacity.cfg has:

      [VST]
      Enable=0
      Rescan=0

      then Audacity will not scan for VST plug-ins. It will if those lines are "1" or missing.
  • Options to deal with this:
    • Only scan for VST effects if the user specifically asks (by setting the Rescan preference)
      • Bad side effect: "Why doesn't Audacity find my VST effects?"
      • Gale: Probably an unacceptable side effect.
    • Hold alt/option on launch to disable all effects (except Nyquist?)
      • Shortcoming 1: the problem may not have to do with effects
      • Shortcoming 2: a bit esoteric, and not discoverable.
    • Hold alt/option on launch to reset preferences and disable all effects
      • Shortcoming: the problem may have to do with effects and not any of the other prefs that will be reset
      • Gale: Or that and more is in James' safe mode.
    • Gale: Would an aggressive timeout per effect help?
      • James: Please clarify. A timeout on loading each effect? We can do more to be crash-resistant on effect loading, but crash-proof isn't possible. A rogue effect can always write anything anywhere in Audacity memory and so cause crashes later. A time out on effect loading won't stop that. An extreme solution is for Audacity to launch a separate test program (that might crash) to load and test each VST plug-in, before Audacity risks loading it itself. Only the test program crashes, not Audacity. That's more work than I think we are likely to do. Anything less than that is in Audacity's workspace and could crash Audacity.
      • Gale: Yes a timeout on loading. I was thinking more of slow loading effects than crash prevention, primarily extreme slow loading of third-party Audio Units. Slow loading can be a predictor of crashes though.

Personal tools