However, I currently have done some changes which I'd like to commit if you are fine with them, so here they are:
- Fixed some capitalization mistakes ("Remove transformations" ->
"Remove Transformations", etc)
I left these because I'm still undecided on whether we want the Initial Caps style. To me it sounds old-fashioned and clunky, I would like to change everything to First cap only. But it's not something I feel too strongly about, so if HIG mandates Initial Caps without exceptions, I can live with that.
and added ellipses were appropriate (like "Import..." and "Export Bitmap...")
OK
. I also changed "x:x" in the View menu to "Zoom x:x" as in Totem. We shouldn't take it too far with the abbreviations. ;)
OK
- Added mnemonics. For this I had to change some functions to their
_with_mnemonic counterpart and also had to add some underscores to many action names (for example "Open" would become "_Open"). I hope this is not a problem. It should only be a problem, if those action names are meant to used at places where mnemonics can't be used. And if they are, we have a major problem.
Wonderful, I meant to do this myself but never had the time. Just check the KeyboardShortcuts wiki page to see if there are any conflicts, and if not we're probably fine (and we tried to avoid alt-letter shortcuts, so there should not be many conflicts if any).
- Changed the position of the "View" and "Object" menus. View is a
standard menu which should come at the third position according to the HIG, application specific menus should come after the standard menus.
Hmm. OK.
- Removed shortcut labels from the context menu. This is according to
the HIG to reduce clutter.
Disagree. "Reduce clutter" is not a strong enough argument for me. The sooner the user will learn shortcuts, the more productive he will be, so I'd like to use any opportunity to remind the shortcuts.
The whole menu stuff in Inkscape seems to be pretty non-standard and I wonder if it wouldn't be worth simplifying the code (maybe using the new action-based API from libegg which will be in Gtk 2.3?). I mostly don't like the way how items with shortcuts are constructed as a new container, as this makes it impossible for Gtk to properly space the menus (notice how in other Gtk apps, the item labels never overlap with the shortcut labels of other items, but they do in Inkscape).
Without overlapping, I think some menus may become too wide. But it's a minor point, so if you can make the menu code more standard (and ideally simpler), go ahead.
Other obvious HIG issues which I didn't touch yet:
- The shortcut labels are non-standard. :) Aside from the already
mentioned lowercase letters, they also use the wrong ordering sometimes (Ctrl+Shift+C would be Shift+Ctrl+C in other Gtk applications) or wrong names (PgUp should be Page_Up).
Order of modifiers: is this a HIG standard or simply "other apps do this"? If the former, well, OK. Otherwise, I like Ctrl-Shift better, because it seems to be standard on Windows, and besides it's more natural because it's the order in which most people actually press these keys (Ctrl, then Shift). So I'd like to leave this as is unless there's some strongly worded and convincingly argued standard on this.
Key names: actually I wrote a special function (sp_key_name in interface.cpp) to translate from the ugly GDK names to normal ones. Mostly it replaces monsters like "asciicircum" by its character, i.e. "^", but also changes Page_Down. Reason: (1) it's overly long and unwieldy, (2) the "_" character is not really meant for user consumption, it's a programmer's device, and (3) PgUp/PgDn is standard on Windows. So I would like to keep this as is.
- The context menu is really bad. You probably know that already. :) The
main point of the context menu is to provide quick access to the most commonly used action on an object. Most commonly used actions should be at the top and sub menus should be avoided. Of course the current context menu breaks all of this. :) This deserves some discussion and a good plan IMO. Maybe a Wiki page?
Yes. One idea I'm planning to do is a node context menu with common operations on a node. However I keep postponing this because I myself never use context menus, and you know... scratching your own itches etc. :)
- The title name of the app is "Inkscape: Documentname: base: X".
According to the HIG it should be either just "Documentname" or "Documentname - Inkscape". I don't know yet what this "base: x" is supposed to be, only that it looks odd. :)
"base" is the namedview. I think we can drop it. But the digit must be kept, it the number of the view (call View/New view, it will show the same document with ": 2").
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
Which one, primary or secondary?
- Storing window size when a window is closed and restoring this size
when a new window is opened. Currently new windows open way too small for my resolution. Would that be ok?
Done yesterday :) see my message "namedview news"
- Dialog reorganization. :) Should I know anything (besides what's
written on the Wiki pages) before I play around with this? Did anyone already work on it?
Nothing except that there were plans to switch us over to Gtkmm, so I postponed this until after the switch because I really don't know what is Gtkmm and how it's going to be different from the current code. However, perhaps the change will not be too drastic and hopefully automatic enough, so if you can work on dialogs now, that would be fantastic. Especially building the Preferences dialog (yesterday I split its wiki page into several sections, perhaps to be implemented as separate tabs; not all controls are ready to be implemented, but some are; those that are ready have the corresponding pref path in []; see the HandlingPreferences page for how to access the values).
_________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus&pgmarket=en-ca&RU=http%3a%2...