Subject: UI design Q -- do people like "sticky" settings?
From: Paul Rohr (paul@abisource.com)
Date: Tue Feb 15 2000 - 17:36:45 CST
The following design issue came up in a private discussion with Alexey
Sinutin, who's implementing overwrite mode, and I thought it'd be worth
coming up with some more opinions.
Essentially, we currently have two sets of functionality in the UI which
allow users to directly change settings on a per-frame basis. However,
there's a discrepancy in how persistent that change is.
1. The most recent case is View/Ruler. There, any time you change the
state of a single frame (via the menu), it *also* updates the underlying
option, so that any new windows "look like" the last one opened. However,
it does not affect the state of any previously-opened windows.
(This "sticky" behavior -- change it once and it keeps applying until you
change it again -- is analogous to toolbar, etc. settings in Web browser
windows.)
2. By contrast, the F12 key, which is used to cycle between input modes
(from default to emacs to vi and then back again) does *not* update the
underlying option.
the question
------------
I personally happen to like behavior #1, so I'm tempted to suggest that #2
should be changed to work the same way. However, I almost never change
keybindings, so I'd like to hear from folks who do.
What do you think?
Paul
PS: Note that to get the full effect of #1 above, we'll need to fix another
bug as follows:
- If you're using a custom scheme *and* you have autosave prefs turned on,
then the "sticky" change will persist to future sessions.
- However, if you're still using the builtin scheme, the "sticky" change
gets lost between sessions even if you have autosave prefs set.
The reason this happens is because the app doesn't know to change schemes,
and the _builtin_ set never gets saved. To fix this, we'd need to move some
of the existing scheme-swapping logic out of the options dialog and into the
prefs or app class (I'm not sure which), which'd be a good idea anyhow.
This archive was generated by hypermail 2b25 : Tue Feb 15 2000 - 17:31:17 CST