On Wed, 24 Dec 2003, Daniel Borgmann wrote:
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. =)
Likely true. Even doing just a subset would probably be valuable, especially if the remainder could be identified as discrete tasks that others could do later. Basically, my thinking is that it would be nice if we had a grasp on "how" compliant it is, and a way to know when we can say we've completed the HIGification work.
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. ;)
Good, that helps make the menus more consistent with standards.
- 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.
I think Bulia would be the best to give feedback on this one.
- 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.
Okay.
- 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).
Hmm, IIRC Bulia put these in deliberately, so I would discuss this one with him before committing it. He had some reasons for doing it so it would be good to gain concensus with him. I suspect it will come down to needing to make a decision whether we want to actively promote learning the keyboard shortcuts vs. strict adherance to the HIG. It may be in this case that the arguments favoring learning would take precidence over merely "reducing clutter". Talk with Bulia and get his take on it.
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.
For this talk with Mental. Also keep in mind that we want to convert all of this to Gtkmm at some point anyway, so I think if you'd be up for rewriting it, that may be encouraged. However, make sure to discuss with Mental regarding handling of verbs, as he has definite plans for where we're going with that.
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).
This sounds like a good change, to me, but get Bulia's feedback on this, just to be sure you're on the same page with it.
- 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, the context menu needs heavy rework. Discussion and planning on Wiki is a good idea. Also, I think if you'd like to go ahead and start revising it, it'd be well received. Probably send in your first few couple tries as patches for review - Mental would be good to give some feedback that you're using the right approach.
I have a sense that getting the context menu right would be a killer feature for Inkscape, since it can be such a dominant input mechanism for mouse-oriented artists, so this would be a high priority item.
- 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 probably the name of the root node in the XML doc. No idea why that would show up in the title. I'd say go ahead and make this change, as to my knowledge there are no stakeholders for the current approach. So this can be a normal 'patch first, discuss later' thing. I think it'd be nice to keep 'Inkscape' in the name, if feasible.
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
So it would be great to have some decisions on those issues.
I showed the app to a co-worker yesterday and he had the same comment. Especially with the raise/lower buttons, which are difficult to distinguish. I wonder if the old pre-0.27 Sodipodi icons would be better?
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?
Yup, give it a shot and we'll see what folks think of it.
- 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?
You're welcome to get started on this one. The thinking was that we would do this as we converted each to Gtkmm, but there's probably little reason not to do one before the other. A nice mockup of a replacement for the object properties dialog was done; you should be able to find a pointer to it from the news archive page on the website. All of the established thinking is on Wiki, although Mental and/or Bulia may be worth mining for additional ideas. In any case, to my knowledge nobody is actively working on this currently.
Make sure to do this work in a CVS branch. This way you can have folks the reorganized approach you'll be proposing before it gets committed to the main branch.
Bryce