On Tue, 2003-12-23 at 22:50, Bryce Harrington wrote:
Regarding HIG, yes it's definitely something we're committed to, although I think we all still wish to see the HIG issues brought up on the list so we all have a chance to understand them. It's even possible we may find some given HIG item to actually hamper the interface, and so we want to ensure we can identify those items for deeper investigation. It's possible we may choose to not follow the HIG on some item, and/or try to feed that decision back into the standard.
Alright, that sounds reasonable. I think I'll just hack away on smaller issues and then ask before I commit.
One thing that could be very useful at this point would be to simply list the areas where Inkscape has HIG compliance issues. This would allow folks to voice thoughts about items that'd be important and/or easily fixed low hanging fruit, and so the list could be prioritized.
Yeah I thought about that, however reviewing the entire application and making sure everything is confirm, is actually quite an undertaking. =) So I decided not to try to do it all at once (maybe we are lucky and someone does a real UI review of Inkscape).
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) and added ellipses were appropriate (like "Import..." and "Export Bitmap..."). 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. ;)
- 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.
- 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.
- Removed shortcut labels from the context menu. This is according to the HIG to reduce clutter. To make this possible, I added sp_ui_context_menu_append_item_from_verb(), which does the same as sp_ui_menu_append_item_from_verb(), but without drawing the shortcut label. This might not be the most elegant solution, but I thought it was better than to change the existing function call (correct me when I'm wrong).
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). And I don't think that this can be solved easily without rewriting some parts of the menu handling.
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).
- 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?
- 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. :)
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
So it would be great to have some decisions on those issues.
Other than that, I'd like to look at the following things next:
- 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?
- 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?
Daniel