GNOME Bugzilla – Bug 138277
Reverse order of OK/Cancel/Other buttons for Windows builds
Last modified: 2004-12-22 21:47:04 UTC
Description: The new version of the GIMP follows the Gnome style of placing the OK, Cancel, and other buttons. From what I can tell this style is a reversal of how Windows does it: For example, the the Gnome style is ordered as follows: [Optional button] [Cancel] [OK] However, all native windows applications are ordered as follows: [OK] [Cancel] [Optional button] Problems: 1) Basically, this can (and will) cause potential conflicts for windows users. People will be used to having the OK and Cancel buttons in other places and may slip up by pressing the wrong button every now and then. The reasoning behind this is based on how we think. Once we learn a certain behavior well enough, we can often do it without having to think about it in much detail -- it becomes second nature to us so to speak. With the OK/Cancel button, this same thing applies. The user becomes so accustomed to where the button is that he will often click on the right spot without even reading the words: it has become second nature to him. 2) Also, this idea of it being second nature to a person leads to another point. Switching the button order on Windows builds will cause some delay in using the dialogs in GIMP. Because the individual has to read the buttons more throroughly and think through the process (instead of relying on second nature), there is a slight delay in picking the right button. BTW, I wanted to mention an example where I actually encountered these issues. At the time, I hadn't used the new version of the GIMP for very long (I still haven't). However, I did notice the change in the order of the buttons. Anyways, I had the "New Image" window open, and was gonna click the "OK" button to create a new image. However, instead of clicking the "OK" button, I found myself clicking the "reset" button over and over again. It had become such second nature to me to have the OK button in that location, that even though I had noticed the differences in the buttons earlier, I still was clicking the other spot out of habit. Eventually I caught myself, and actually took some time to look for the right button, but the overall process did end up taking more time. As this example illustrates, the location of buttons can become quite ingrained, and changing their locations are likely to cause some disruptions (and even dataloss) in some cases. Proposal: Thus, I basically propose that we used the Windows button order for Windows builds of the GIMP. From what I have seen, this means the reverse order of the Gnome style. I hope that this idea of separating things between Linux and Windows builds does not deter this being done. Perhaps it might be worth noting that the Firefox project does this same thing of separating how Linux builds and Windows builds handles the order of the buttons. For the benefit of Windows users, I believe it would be beneficial to do this in the GIMP, as well.
Isn't this something that should be handled globally in GTK, possibly through a Windows-specific theme or something? (Compare to how GTK dialogs in general get flipped left-right in RTL locales.)
I don't really know the details about how GTK works with the GIMP. However, whatever the solution to this is, it would be helpful if the the burden is not placed on the user of the GIMP to fix it. In other words, it would be much prefered if this solution could be fixed at the code level, or at the compilation level, or even at the setup level (when the program is installed), but not at the usage level. -- Most windows users will probably just install the GIMP and leave it at that (without configuring much of anything).
*** This bug has been marked as a duplicate of 74669 ***
Until Bug 74669 is fixed, is there any kind of temporary solution that people compiling windows builds could implement?
You could help fixing bug #74669. There's no other way.