GNOME Bugzilla – Bug 92468
[TRACKING BUG] Compliance to GNOME HIG
Last modified: 2005-08-15 01:46:00 UTC
I think that GIMP should follow the GNOME Human Interface Guidelines (http://developer.gnome.org/projects/gup/hig/1.0/) as much as possible and as much as makes sense of course. This will have quite some impact. I propose to keep this enhancement report open and file new enhancement reports with smaller tasks (for example using Shift+Ctrl+Z for the Redo action instead of the current Ctrl+R).
I suggest that you create the separate bug reports (e.g., Shift+Ctrl+Z for Redo) and mark them as blocking this one. We will then flag this bug report as a tracking bug, with dependencies on all others. There is already another example of such a tracking bug for the GIMP: see bug #70335 if you want to see how it looks like.
Created attachment 17739 [details] [review] menu patch and stuff
the above patch changes the shortcut for undo to Ctrl+Shift+Z amongs other things (Turn Left, Rotate 90 Ctlr+R, Crop Ctrl+Y).
I was surprised when I read your comment about changing the shortcut for Undo, but fortunately this is the shortcut for Redo that was changed to Shift-Ctrl-Z. On the other hand, I disagree with "Turn Left" and "Turn Right". This was already discussed in bug #57797 and I would not like to reopen that discussion now (at least not until the next major release). Your patch mixes some parts that are fixing this bug (shortcut for Redo) together with new features that are unrelated to this bug report (new shortcut for Crop and changes in the menu names). In general, this should be avoided.
As I told you on #gimp, you should discuss this on the mailing list. BTW, we had a lengthy discussion about the names of the rotate menu entries and the current strings are the result of that discussion. "Turn Right" and "Turn Left" are totally insane IMHO and I fail to see why we should change the redo binding people are used to. You can always change the default keybindings if you don't like the defaults.
From my point of view, I think that Alan's suggestion to change the default binding for Redo is fine. This is what is suggested by the GNOME HIG (so it is used by several GNOME apps) and this is also used by Apple and by some other programs like Photoshop. Changing the default binding makes sense and will help new users. If some experienced GIMP users prefer Ctrl-R, it is still possible to rebind the key, which should not be a problem for experienced users anyway. On the other hand, I disagree with renaming the menus (see bug #57797) and with the new shortcut Ctrl-Y for Crop. In fact, we should probably never assign any meaning to Ctrl-Y in the default bindings, because this is the shortcut for Redo on Windows (e.g., all MS office apps) and in Mozilla.
Raphael, sorry my mistake, you are right I meant Redo. I will discuss Redo first and deal with the other changes later. Yesterday I mistakenly sent a mail to the list owner instead of the developer list. I resent it correctly to the list this morning. I would post a link to the web archive of mailing list archives but they seem to be suffering severe delay (or are just broken) > You can always change the default keybindings if you don't like the defaults. That goes both ways, and Experienced GIMP users are more likely to already have customised keybindings or at least know how to change them. > I fail to see why we should change the redo binding people are used to. My post to the mailing list explains this in extentisive detail. When it comes to image editing on *nix the GIMP is a defacto standard, there are very few alternatives. I would not go to all this effort to change the defaults if it was just about me, I could take the easy way and just change my own local keybindings. I am trying to give the best possible solution for the most people possible and at the same time accomodate and work with existing GIMP users as much as possible. Please try not to be too critical. It is really difficult when changing the keybinding for Redo could be so controversial and require such detailed justification. I am trying really hard but it is impossible to please everyone.
Perhaps we need hig-menurc ?
in my mail to the list (I am on the digest, dont know if it has arrived yet) I suggested a menurc for people who like thing the way they are.
Created attachment 17809 [details] [review] sames as previous patch but without contentious changes to Rotate
I would prefer to limit the patch to changing the shortcut for Redo and drop the other parts. I am convinced that changing the shortcut for Redo is a good thing because it brings more consistency. However, I think that we should abstain from binding the combinations Ctrl-R and Ctrl-Y to anything, until after the next major stable release. Ctrl-R should not be used because it could confuse those who upgrade from 1.2 to 1.4. Ctrl-Y should not be used because this is the default Redo key in Windows. In fact, I would argue that _both_ Ctrl-Shift-Z and Ctrl-Y should be used for Redo in 1.3.x and 1.4. This is currently being discussed on the gimp-developer mailing list, so let's see what comes out of that.
There is however no reason to attach a patch at all. If we decide to do this change, it is easier made manually than by applying a patch.
I got my build enviroment sorted out and built the GIMP the two patches I provided wont work as I am fairly sure I left out some "inverted commmas" I would provide them again but it was suggested that someone would manually patch Redo and that I was not going to get my other changes accepted (or that I would have to wait until a major release eventaully happens and ask again).
I set this one to Future since I don't expect GIMP 2.0 to be HIG compliant. If we want this it's probably best to wait for some HIG compliant GTK widgets, for example to replace frames (after lengthy discussions :) )
This really should be made into a tracking bug.
I've done some changes to the menu labels yesterday basically following the HIG suggestion on ellipsis in menu entries. This brings us a little closer to total HIG compliance (if that's a desirable goal at all).
The fix for bug #125143 also removes the separator from all dialogs. One step closer to HIG compliance ...
Adding the PATCH keyword.
Removing the PATCH keyword again since this report is more a tracking bug and it doesn't have any patches attached that are still being considered.
Work has now started in CVS to convert all dialogs to the HIG suggested layout. We will start by converting use of GtkFrame to GimpFrame and by adjusting dialog spacings. We should also make use of GtkExpander where it makes sense.
I would urge caution when changing the dialogs because the HIG was clearly not intended to deal with the kind of non-transient dialogs aka palettes that the Gimp User Interface makes considerable use of. For dialogs that are intended to be always on and where space is at a premium, like the Layers/Brushes/Patterns it might be worth looking at the GPE (Gnome Palmtop Enviroment) HIG because they have thier own exceptions to the Gnome HIG because space is so essential to them.
I mentioned this on gimp-developer already. We will need a more compact layout for our dockables. So far I only changed temporary dialogs. The changes to libgimpwidgets do already affect some tool-options however. One way to deal with that is to introduce more style properties to GimpFrame and other widgets that we use to get a HIG-compliant dialog. By style properties we can change the spacings for widgets that appear in GimpDockables. We do this already for the spacing between the frame title and the frame content. We could theme the appearance further.
Doesn't even look too bad but we still have quite a lot of old-fashioned frames in the tool-options: 2004-05-04 Sven Neumann <sven@gimp.org> * libgimpwidgets/gimpframe.c: added a style property to control boldening of the frame title. * themes/Default/gtkrc * themes/Small/gtkrc: suppress the bold title for GimpFrames in GimpDockables,
Relevant HIG link is now: http://developer.gnome.org/projects/gup/hig/2.0/
It would probably make the gimp more consistant with the HIG and help users if there was a Help menu included in the document menubar and right-click menu (like in Dia).
All bugs that this tracker bug depends on have been fixed. Does it make sense to keep it open still? Are there particular places that need to be changed still?
I think this one can be closed. If any HIG issue comes up again we can file a new bug report, but it doesn't make much sense to have a tracking bug anymore.
*** Bug 166474 has been marked as a duplicate of this bug. ***