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...
OK, then please go ahead and unify that.
- 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.
To me, it's more consistent when all menus show shortcuts, no matter context or not.
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.
Exactly BECAUSE they want quick access, they will be glad to learn that there's a still quicker access, via the shortcut :)
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. :/
They are equally important. Winning users from Windows or Mac is of major importance, simply because it's by far the biggest source of new users. Given that Linux was feeling all right without a good vector editor for many years is an indication that the core users of Linux may not need such an application all that much. On the other hand, I'm an example of a person who've been rebooting into Windows for the vector editors (in my case, it's mostly Xara X) until I found Inkscape and spent some time on making it usable for me (with much help from others, of course - something that makes Inkscape very different from e.g. Sodipodi). So now I do simple designs in Inkscape, although I still have to reboot into Windows for more complex tasks.
To summarize, neither Windows nor Gnome are the final authority for us; but both are worth consulting. Where HIG is in minor disagreement with Windows or Mac practices, we should follow HIG (unless doing otherwise brings some sizable benefits). But where following HIG literally might seriously alienate or confuse Windows users, we must be extra careful.
Ideally each decision should be taken based on usability tests with real users, but lacking that, we need to put forward convincing arguments in addition to references to standards or conventions.
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
That's a counterpoint, but still I'm not convinced. I think following the natural order of pressing buttons is of major importance for the shortcut to be easy to memorize. Anyone else has an opinion?
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...
I needed a shorter variant for Page_Down, and Windows has one. Why not use it?
"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?
Good idea I think.
- Toolbar is non-standard (also looks ugly with Bluecurve theme :/)
Which one, primary or secondary?
Secondary.
OK, you could work on it too, see SecondaryToolbar on wiki for the plans :) The difficulty with it is that we want to put both buttons and other kinds of controls there (spinbuttons, lists) and it may not be straightforward to combine them neatly.
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?
May be relatively easy to implement, although now I don't see an urgent need for that.
- 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.
I think this is wrong, because if I have several documents open with different window sizes and I quit Inkscape, the size of the new one will depend on which was closed last, which is almost random (from user perspective anyway). So this behavior might be confusing. I think it's better to decide once and for ever that "I want new documents to be this large" and put this into the template.
Again, anyone else has an opinion on this?
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?
I think Nathan Hurst or Mental are the right persons to ask this question.
_________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963