Re: [Inkscape-devel] User Interface(was: save confirm dialog)
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...
On Wed, 2003-12-24 at 19:09, bulia byak wrote:
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.
Yep it does. And to me, being used to it, everything else looks like an oversight and thus unprofessional. :) It's described here: http://developer.gnome.org/projects/gup/hig/1.0/layout.html#layout-capitaliz...
- 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).
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.
Hm ok, I'll revert the change. However, to be honest I don't understand the reason and I really don't believe that it is a strong enough reason to break consistency. Users can learn the shortcuts from the main menu and users who use the context menu usually do that because they want to have quick access to a certain function, not because they want to see the shortcut.
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"?
I think it's simply "(all) other apps do this". Though the HIG also very strongly suggest to follow other apps whenever possible for the sake of consistency. :)
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
Is consistency with Windows more important than consistency with GNOME? That would be a mild disappointment for me. :/
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.
Again, I don't think that this is a good reason to break consistency. There is also a good reason for Shift+Ctrl+X: Most shortcuts are Ctrl+X, Shift+Ctrl+X is usually only used when this one is already taken. So putting Shift on the left side will make the items align better: Bounce Ctrl+B Frobnicate Ctrl+F Foobar Shift+Ctrl+F as opposed to: Bounce Ctrl+B Frobnicate Ctrl+F Foobar Ctrl+Shift+F
I personally find the former to be much better readable. Another point is, that it might confuse GNOME users who are used to this ordering and will expect it in a real Gtk app.
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.
Hmm ok. Again, the break of consistency kinda irks me and the "is standard on Windows" irks me even more. ;) But right now this a minor issue anyway...
- 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").
Ok. How about showing the ": x" only when it's two or higher? Then we don't have to show the ugly ": 1" behind each title (most of the time you probably have only one view active anyway). It would also make it a bit more obvious was this number is supposed to be.
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
Which one, primary or secondary?
Secondary. Primary is fine. Though the HIG mandates that if a vertical toolbar is used, the user should be able to make it horizontal. Probably not very important, but I wonder if we could make it possible to also dock it at the top when it's dragged around?
- 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"
Oh, great! :) I missed that. But this doesn't work for new documents, right? I mean without using a template. It would be nice if a new document would always open with the size of the last window I closed.
- 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).
Alright, I'll have a look at the preferences dialog then, this was interesting me anyway. :) For everything else I'll wait for the conversion to Gtkmm, as I'm really looking forward to that. Is there any estimate already when this switch will occur? I couldn't find it in the roadmap. Is there anything I could do to help with this?
Daniel
On Wed, 24 Dec 2003, Daniel Borgmann wrote:
- 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).
Alright, I'll have a look at the preferences dialog then, this was interesting me anyway. :) For everything else I'll wait for the conversion to Gtkmm, as I'm really looking forward to that. Is there any estimate already when this switch will occur? I couldn't find it in the roadmap. Is there anything I could do to help with this?
Daniel
We were thinking about converting one dialog over to Gtkmm and then do a thorough code review, figuring that if we can spend extra time doing a good job with the first one, then we can have others use that as the model for the remaining ones. So what you could do right now is choose a dialog and sketch out a preliminary, rough reimplementation of some sort in Gtkmm and have people throw darts at it. Again, be sure to do it in a branch. If it turns out well, we could include it as a preview in 0.37, but let's plan on folding it into 0.38 immediately after the 0.37 release. The full Gtkmm switch has been planned for 0.38 or 0.39, depending on how ready we feel we are to do it.
Bryce
participants (3)
-
Bryce Harrington -
bulia byak -
Daniel Borgmann