Re: [winecfg 8] Complete drive edit dialog, warn on lack of C drive, implement drive delete, code cleanups
On 11 Sep 2003, Mike Hearn wrote:
ChangeLog: - All settings in the drive edit dialog are now instant apply
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. I'd argue that we need to support instant apply to integrate with GNOME, but to default to the classic OK/CANCEL for now, until we can figure how and when to enable one or the other behaviour. -- Dimi.
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. 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. 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'd argue that we need to support instant apply to integrate with GNOME, but to default to the classic OK/CANCEL for now, until we can figure how and when to enable one or the other behaviour.
Maybe, but having two different behaviours could itself be pretty confusing. I'll implement revert in dialogs where there is clearly a need (the drive edit is probably one of those areas), but in others the only value I can see for having a cancel button is to follow what Windows (which basically doesn't having much of a HIG at all) and KDE (which typically follows windows) do. Having revert/close then is basically like OK/cancel except the buttons are labelled differently - the functionality is the same. I'd recommend you try it anyway, and see how it feels. Certainly I found instant apply felt much snappier, simpler and more understandable - so far I haven't missed cancel buttons (but otoh i was never one to change a setting, hit apply to see what it did etc, i just changed them). thanks -mike
On 11 Sep 2003, Mike Hearn wrote:
drive edit is probably one of those areas), but in others the only value I can see for having a cancel button is to follow what Windows (which basically doesn't having much of a HIG at all) and KDE (which typically follows windows) do. Having revert/close then is basically like OK/cancel except the buttons are labelled differently - the functionality is the same.
But it's not the same, it's different. It's not what users expect. Windows is on 90% of desktops, KDE is on mode that 70% of Linux desktops. Which means 99% of people are used to OK/Cancel. I don't want to debate which one is better, this is not the point. In fact, I might agree with you that instant apply makes sense. But the truth is that it's not such a big improvement, nowhere close to warant breaking from the status quo. Just think how weird this will look on a KDE desktop. Or to any Windows user, our target audience! This has been tried ad nausaem before, and have failed consistently _every_single_time_. It just doesn't play to break consistency like so because you think in this case it is a bit better. What's the reasons to try it yet again, with very predictable results? -- Dimi.
On Thu, 2003-09-11 at 16:47, Dimitrie O. Paun wrote:
But it's not the same, it's different. It's not what users expect.
I don't think it's a hugely big deal to be honest, I've yet to see anybody have major problems with it in Gnome, the difference simply isn't that huge.
Windows is on 90% of desktops, KDE is on mode that 70% of Linux desktops.
Hmm, I'd question those statistics, I know quite a few people who don't use any desktop at all.....
Which means 99% of people are used to OK/Cancel.
95% of people are used to Windows, but we're building an alternative nevertheless, which in some cases is quite different.
I don't want to debate which one is better, this is not the point.
Well, I don't see why not. Basically you are saying that because OK/Cancel is what people are used to, that makes it better.
In fact, I might agree with you that instant apply makes sense. But the truth is that it's not such a big improvement, nowhere close to warant breaking from the status quo. Just think how weird this will look on a KDE desktop. Or to any Windows user, our target audience!
I thought our target audience was people who didn't want to be Windows users anymore ;)
This has been tried ad nausaem before, and have failed consistently _every_single_time_. It just doesn't play to break consistency like so because you think in this case it is a bit better. What's the reasons to try it yet again, with very predictable results?
I think you are mixing up API improvements with UI improvements. When Wine has tried to improve the API, yes it has failed but computer programs are far less flexible than people, so it makes sense to try and match Windows perfectly there. This program doesn't even have a Microsoft equivalent, so I don't see any reason why we shouldn't try and make it the best we possibly can. thanks -mike
On September 12, 2003 08:18 am, Mike Hearn wrote:
I don't think it's a hugely big deal to be honest, I've yet to see anybody have major problems with it in Gnome, the difference simply isn't that huge.
And this is my very point -- it's not significant enough to break consistency. Breaking GUI compatibility is as breaking APIs simply because they are both interface. Histroy shows that you should not break interfaces for frivolous reasons. The current situation is not very nice: we have a dialog looking exactly like a Windows dialog, with an OK/Apply button (!), that behaves like a ... something else, without any indication whatsoever. This is like arguing to swap the strcpy() params because you don't like the order, but you can't change the name since so many programs use it. Imagine a Windows user that just migrated to Linux/KDE using this thing -- he will not be happy for the simple reason that it will make him/her feel stupid. Right now we are not only inconsistent with (many) of our running environments, we are also inconsistent with everything else we do in Wine, as well as every application the user will run through Wine. I suggested a compromise: let's keep this configurable so we can nicely integrate with the running environment. I'm surprised you find this suggestion so controversial. -- Dimi.
On Fri, 2003-09-12 at 14:22, Dimitrie O. Paun wrote:
The current situation is not very nice: we have a dialog looking exactly like a Windows dialog, with an OK/Apply button (!), that behaves like a ... something else, without any indication whatsoever.
You realise that's temporary, right? Quite a lot of winecfg doesn't do anything, is inconsistant, confusing etc - it's basically a building site right now.
Right now we are not only inconsistent with (many) of our running environments, we are also inconsistent with everything else we do in Wine, as well as every application the user will run through Wine.
I suggested a compromise: let's keep this configurable so we can nicely integrate with the running environment. I'm surprised you find this suggestion so controversial.
Not really controversial, it just makes a bit more work, and I tend towards the "try to get it right" rather than "let's just make it configurable" line of thought. But whatever. Fine, I'll make it a command line switch or something....
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
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
I haven't tried yet I was just wondering: What happens if a user selects native, builtin but hasn't a copy of the MS-DLL? Nothing, wine then just loads the native. Is it possible to just enter native (without builtin) so wine prints an error if the MS-DLL is not found? I'm sure that many people would just change this setting and forget to (or don't even know they have to) copy the dlls from a Windows system. bye Fabi
On Thu, 2003-09-11 at 21:52, Robert Shearman wrote:
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.
Maybe, but why do we have settings that could be potentially catastrophic anyway? Sounds like a recipe for more tech support traffic to me.....
Now some comments on winecfg after using it for the first time (I realise that winecfg isn't finished yet):
Right, nowhere near :)
1. The 'Apply' button seems to be enabled by just flicking between tabs in the dialog
The Apply button in the main window doesn't actually do anything. Unfortunately the PropertySheet API is rather limited in the options it gives you.
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?)
Well, at the moment, that's every setting in the entire program. Long term, there's no reason why settings shouldn't be changeable at runtime though, the registry API supports change notification.
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)
Yeah, I haven't even looked at that code yet, it's exactly how I found it.
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).
Odd. I thought I had got it so at least one item was always selected. Have you got all my patches applied? I think some are still pending.
5. It would be nice to have fixme's printed on buttons that don't work yet, etc.
I've started doing that with WRITEME() which is a fixme but in a dialog box, but so far not much stuff uses it. thanks -mike
participants (5)
-
Dimitrie O. Paun -
Dimitrie O. Paun -
Fabian Cenedese -
Mike Hearn -
Robert Shearman