On Thursday 11 September 2003 4:39 pm, you wrote:
On Thu, 2003-09-11 at 16:20, Dimitrie O. Paun wrote:
This is a cool feature, but we should keep it optional. Our primary audience are Windows users, and they are not used to that. Heck, even I am not used to it, I am used to be able to play around with stuff in dialogs, and than press CANCEL. In fact, KDE is not instant apply, so I would argue that even most Linux users are used to that.
That is a valid point, but I would counter that if we have settings complex enough that a reasonably normal person cannot remember what they changed, they shouldn't be settings at all. Now, that's fine for check boxes, combo boxes etc, for the drive configuration there are quite a lot of text edits, so some kind of revert/cancel function may well be a good plan.
Once they've applied the changes then it should be up to the user to revert whatever they have done. Otherwise, cancel should just discard any changes they have made since opening the dialog or since the last apply.
On the other hand, I've met quite a few people who don't grok the difference between "OK" and "Apply". They press Apply, nothing changes, and they think "what just happened?", especially in this case because you have to restart the apps running under emulation to see the effects.
If the user doesn't realise that Apply applies the changes then the user will probably not be able to use Wine anyway. Though personal experience suggests the converse to this; people are more likely to press 'Apply' before pressing 'OK' because they think that 'OK' doesn't apply changes.
The other confusing thing is that if you click OK, then reopen the dialog, Cancel no longer does anything. That's confusing because most people don't make a link between the dialog disappearing, and the changeset being committed then freed.
I'm confused with this statement. The point of 'Cancel' is to close the dialog without saving any changes made in that dialog. If you've already saved the changes from the first time then it is your problem to try and change them back. If the changes are potentially catastrophic then you should be either warned before making them or prevented from making them in the first place. We can't predict whether the user *really* wanted to make those changes so we have to assume they did. They can always change them back later.
Now some comments on winecfg after using it for the first time (I realise that winecfg isn't finished yet):
1. The 'Apply' button seems to be enabled by just flicking between tabs in the dialog 2. If the option changed cannot be applied instantly, then a dialog box stating this should be displayed (e.g. do you want to restart all of your programs?) 3. I know the load order page isn't finished yet, but a dropdown box for the load order with the options "builtin then native" and "native then builtin" would be better than the radio buttons (but we should keep the explanation about builtin = Wine and native = MS, which is very useful) 4. The drive dialog: the edit and remove buttons shouldn't be enabled unless something is selected (at the moment if nothing is selected it removes the last item in the list). 5. It would be nice to have fixme's printed on buttons that don't work yet, etc.
Rob