"Use"d settings: application behaviour

[trixie]

Chris and I have recently come across some inconsistency in application behaviour as regards the treatment of "interim" settings - that is, settings that were (in the application's own settings window) confirmed via the "Use" button. There are programs that discard "Use"d settings when the application quits (Netsurf, MUI-OWB) while others (AmigaAMP, ADRipper) keep the intering settings saved in ENV: for further instances of the program to pick up. (In other words, the interim settings remain in place until system reset - this is what the OS prefs editors do as well).

The UI Style Guide is not very clear as to what the correct application behaviour should be in this particular respect. An official word from Hyperion (and an update to the Style Guide in the wiki) would be very welcome!

[xenic]

@trixie
Personally, I really hate it when I can't restart (close/open) a program with my "saved" prefs. I have to manually copy the prefs from ENVARC: to ENV: (if the prefs are saved in ENVARC:) before restarting some programs. However, there are probably times when someone would want to restart a program with the "use" settings. I think what we need is Style guide update that recommends 3 possibilities for prefs changes such as:

SAVE, USE, USE&REMEMBER

The USE&REMEMBER suggestion is a little awkward, so it would be better if someone could think of a word that would convey the idea more concisely. A Style Guide recommendation for a "Load Saved Prefs" or "Restore Saved Prefs" menu item would be a good alternative.

[LyleHaze]

From the doc wiki:
http://wiki.amigaos.net/wiki/Configurin ... nd_AmigaOS

The "Save Use Test" concept, just a paragraph down from the top of page.

Save : make change permanent
Use: Keep change until next reboot, close window
test: apply change, but keep the window open.

[chris]

From the doc wiki:
http://wiki.amigaos.net/wiki/Configurin ... nd_AmigaOS

The "Save Use Test" concept, just a paragraph down from the top of page.

Save : make change permanent
Use: Keep change until next reboot, close window
test: apply change, but keep the window open.

That's only referring to standalone prefs editors.

[trixie]

@LyleHaze

There's a more relevant section in the wiki:
http://wiki.amigaos.net/wiki/UI_Style_G ... ce_Editors

The good old Settings menu is becoming less common as the complexity of software increases. Apps now typically feature a dedicated settings window/prefs editor (built-in or standalone). What we want to know is whether such an editor should behave in the same way the OS prefs editors do ("Use" = remember settings until reboot) or not. Usage in software is apparently inconsistent.

[thomasrapp]

I think everybody agrees that the function of the "Use" button is "apply settings now but forget them when the session ends".

Now it needs to be defined what a session is for each kind of program.

IMHO for the typical application the session ends when the program ends, i.e. when you select "quit" from the menu or something similar.

It is rather unintuitive to keep the current settings past the end of the program but restore them to something saved long ago when the computer reboots.

Of course every settings window should have an option to "restore to last saved", be it a button or a menu or something else.

[ssolie]

The UI Style Guide is not very clear as to what the correct application behaviour should be in this particular respect. An official word from Hyperion (and an update to the Style Guide in the wiki) would be very welcome!

You (wiki editors) control the UI Style Guide now so go ahead and fix it. Figure out what makes the most sense and make it happen. I don't see any need for Hyperion to be involved.

[chris]

I agree with thomasrapp on this.

I see settings changes within an application as an "in memory" thing. They should only persist on next launch if the user has actually saved them. This is no different to the OS, it's just that the only way to restart that is to reboot.

[thomasrapp]

BTW, IMHO it is a misunderstanding that ENV should be used to save temporary settings.

ENV holds what is called global variables.

Workbench uses a set of global variables plus the possibility to get informed when a variable changes to communicate with the external prefs editors. IMHO this does not mean that ENV is the preferred way for all applications to store temporary settings.

[xenic]

BTW, IMHO it is a misunderstanding that ENV should be used to save temporary settings.

ENV holds what is called global variables.

Workbench uses a set of global variables plus the possibility to get informed when a variable changes to communicate with the external prefs editors. IMHO this does not mean that ENV is the preferred way for all applications to store temporary settings.

Actually, I think it a misunderstanding that ENVARC: should be used for permanent program settings. Every time I boot or reboot, 70K of 3rd party prefs get copied to ENV: and there's not much I can do about it.