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