RE: Inkscape minor changes I'd like before the next release (if acceptable)
I've been reading the KeyboardShortcutsToDo document in Wiki http://inkscape.org/cgi-bin/wiki.pl?KeyboardShortcutsToDo
You ask ::(two rotation directions ''times'' two rotation speeds ''plus'' two radial movements) ''times'' two handles for each node ''equals'' 12 keys or key combinations in total! :I'm thinking about how to fit this into the keyboard in a more or less elegant way that can be remembered. Suggestions welcome.
I would venture a guess that a certain amount of context could be used to reduce the requirements for so many unique keybindings.
I think I managed to shape this quite well with [] <> with various modifiers. See the KeyboardShortcuts page (the ToDo needs updating). Try it on a real node path to get a feel.
I'm thinking we should be able to heavily overload the arrow keys. Also my instinct is that treating Alt and AltGr differntly is something that should be avoided if possible.
I'm not sure what is AltGr, but left and right Alts or Ctrls are pretty convenient for rotating the two handles separately. Try it.
I remember you had some objections to when this was brought up http://www.maths.tcd.ie/~horkana/inkscape/jasc-webdraw-tooltips.txt but I cannot quite recall what they were. (Perhaps it was that you didn't like that rotate clockwise was both Down Arrow and Right arrow and similarly Up Arrow and Left arrow were anticlockwise.) I still think the shorcuts used for this by Jasc Web aren't bad.
No. Arrows are for moving. Rotation is different and needs different keys.
Inkscape already uses up and down arrows for Nudging, shift+arrow gives a bigger nudge. Inkscape uses Ctrl+Arrows for some sort of Panning/scrolling but I think this is a waste.
Why? I use it all the time. It's very convenient.
I'm not sure if it is this is a good keybinding for panning but it should not be used when there is a selection.
Panning must not depend on whether there is a selection.
When something is selected then Ctrl+Arrows could be used for rotating it.
No. Confusing. Panning keys always pan. Rotating keys always rotate. That's the way it should be.
When there is nothing selected (and because we know dont want to rotate the whole canvas), we can still use Ctrl+Arrows for panning in this context if that is what we really want to use those keys for.
What you propose is a usability disaster. Accidental rotates when I intended to pan and vice versa will drive me crazy.
Although I'd normally try and avoid using the Alt key for much I do think alt+arrows could be quite useful, if not instead of the keys you have suggested then perhaps for skew/shearing.
Alt+anything has the general meaning of moving slowly, one visible pixel per keypress. That's the way it works with arrows, [], and <>. I can't live without it.
I'm thinking maybe also that you cannot have a meaningful 'rotate' when you are in Node Edit mode (as opposed to the standard select mode)
Yes I can. Select a node and press [ or ].
so we can use these keybindings again for manipulating the nodes. Now that I think about it Select and Node Edit need to be kept clearly seperated out anyway, and I'm hoping this makes a whole huge amount of sense. (Modes like in Vi can be nasty for users but we have them already and may as well make the most if it)
Those operations that are clearly and unambiguously applicable both to objects and to nodes, such as move or rotate, must apply to objects and nodes in selector and node tool respectively. That's just logical.
** ctrl-[, ctrl-] - scale 1/2 or 2 times the original
Now it's ctrl-< and ctrl->. As I said, [ and ] are for rotating.
Unfortunately Adobe Illustrator uses them for Bring to Front Shift+Ctrl+] Brink Forward Ctrl+] Send Backward Ctrl+[ Send to Back Shift+Ctrl+[
Too bad :) I don't think we'll change that to conform to Illustrator because: 1) we already have established keys for back/forward and 2) [ and ] are convenient for rotate. So we'll leave this for the "Illustrator compatibility mode".
I'm conflicted by my sycophantic desire to pander to Adobe Illustrator users and the desire to use the same keybindings as I used for Dia (which if i recall correctly were the same as Visio, see below) and perhaps get other Gnome application to try and use the same bindings consistantly. Only by keybindings being consistant across applications do they become significantly easier to learn and remember.
Send to Back Ctrl+B Send Backwards shift+ctrl+b Bring to Front Ctrl+F bring forwards shift+ctrl+f
Ctrl-b, shift-ctrl-f are already occupied. Ctrl-f will be one day used for search (I hope).
I desperately want the Page Up and Page Down keys back so that they can be used to move up and down the page as the Gods of User Interface Design intended so I have been thinking about the possible shortcuts.
No. In a text editor, the up/down direction is significantly different from left/right so it has additional keys (pgup/pgdn). Not so in a drawing program. Here we have four equally important directions, and they must be equally served by keys. That's why all moves and pans can only be done by arrows, because there are 4 of them. On the other hand, pgup/pgdn can later be used for navigating across "pages" or "layers" of an svg, but that's far away into the future. For now, I like pgup/dn as they are.
Whiel I'm at it I may as well mention that I really strongly want to rename the Dialogs menu with a 'Tools' menu and make it consistant with about a zillion pieces of Software instead of just a handful of ugly software (Gimp, Cinepaint, Sodipodi, Dia).
"Tools" is vague. "Dialogs" is exactly what this menu contains. I see no reason for a change.
Sorry if this mail makes little sense, it was written completely out of order, I originally intended to mail it to the list and I really need to get some sleep and get my damned project finished on time!
I want to sleep too, so replying briefly :)
I found a PDF document that lists some of the shortcuts (keybindings) used by Adobe Illustrator 7.0 http://www.bsu.edu/web/ucspubs/pdf/other/crossprod.pdf
See KeyboardProfiles - if you care about Illustrator, plan a profile as described on that page. I promise to implement loading keys from a file as soon as we have two complete profiles of different mainstream editors.
PPS I figure I must be doing something wrong or overlooking some detail but I cant quite seem to get Inkscape (on windows) to import any Images.
File > Import?
_________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=dept/bcomm&pgmarket=en-ca&RU=http%3a%2f%2f...
On Thu, 29 Jan 2004, bulia byak wrote:
Date: Thu, 29 Jan 2004 05:06:18 +0000 From: bulia byak <archiver_1@...19...> To: horkana@...44... Cc: inkscape-devel@lists.sourceforge.net Subject: RE: Inkscape minor changes I'd like before the next release (if acceptable)
<snip> I'll try and look at this again tomorrow when my head is clearer although I did put a fair amount of thought into my message.
Too bad :) I don't think we'll change that to conform to Illustrator because: 1) we already have established keys for back/forward and 2) [ and ] are convenient for rotate. So we'll leave this for the "Illustrator compatibility mode".
I desperately want the Page Up and Page Down keys back so that they can be used to move up and down the page as the Gods of User Interface Design intended so I have been thinking about the possible shortcuts.
arrows, because there are 4 of them. On the other hand, pgup/pgdn can later be used for navigating across "pages" or "layers" of an svg, but that's far away into the future. For now, I like pgup/dn as they are.
Even though you can think of Inkscape of currently only having one page I think having 'page up' and 'page down' do just that is best. (Even given the importance of Layers in the GIMP I dont think they should be stealing Page Up and Page Down either and that they should use a differnt shortcut).
Whiel I'm at it I may as well mention that I really strongly want to rename the Dialogs menu with a 'Tools' menu and make it consistant with about a zillion pieces of Software instead of just a handful of ugly software (Gimp, Cinepaint, Sodipodi, Dia).
"Tools" is vague. "Dialogs" is exactly what this menu contains. I see no reason for a change.
Consistancey with about a Zillion applications ... Dialog is a really poor label by which to group functionality (Tools isn't significantly better but at least it is consistant). Labelling the menu 'Dialogs' risks encouraging developers to throw things there because they have a dialog and I'd rate it one step above "Miscellaneous", it is not like as the GIMP developers ever gave it much thought and those that copied the GIMP gave it even less thought.
I found a PDF document that lists some of the shortcuts (keybindings) used by Adobe Illustrator 7.0 http://www.bsu.edu/web/ucspubs/pdf/other/crossprod.pdf
See KeyboardProfiles - if you care about Illustrator, plan a profile as described on that page. I promise to implement loading keys from a file as soon as we have two complete profiles of different mainstream editors.
I will still push for the defaults to be as much possible like Adobe Illustrator or failing that another well established piece of professional graphics software so that at least one large userbase will be able to migrate relatively easily to Inkscape. Lots of new and unique keybindings is the worst of all worlds.
PPS I figure I must be doing something wrong or overlooking some detail but I cant quite seem to get Inkscape (on windows) to import any Images.
File > Import?
That was among the things I tried but that didn't work.
Sincerely
Alan Horkan
On Thu, 29 Jan 2004, bulia byak wrote:
Date: Thu, 29 Jan 2004 05:06:18 +0000 From: bulia byak <archiver_1@...19...> To: horkana@...44... Cc: inkscape-devel@lists.sourceforge.net Subject: RE: Inkscape minor changes I'd like before the next release (if acceptable)
I've been reading the KeyboardShortcutsToDo document in Wiki http://inkscape.org/cgi-bin/wiki.pl?KeyboardShortcutsToDo
You ask ::(two rotation directions ''times'' two rotation speeds ''plus'' two radial movements) ''times'' two handles for each node ''equals'' 12 keys or key combinations in total! :I'm thinking about how to fit this into the keyboard in a more or less elegant way that can be remembered. Suggestions welcome.
I would venture a guess that a certain amount of context could be used to reduce the requirements for so many unique keybindings.
I think I managed to shape this quite well with [] <> with various modifiers. See the KeyboardShortcuts page (the ToDo needs updating). Try it on a real node path to get a feel.
I'm thinking we should be able to heavily overload the arrow keys. Also my instinct is that treating Alt and AltGr differntly is something that should be avoided if possible.
I'm not sure what is AltGr, but left and right Alts or Ctrls are pretty convenient for rotating the two handles separately. Try it.
On most of the keyboards I have seen the right Alt key is labelled AltGr (which as far as I can remember is short for Alternative Graphic which is a holdover from back in the days of machines like the Commodore 64 where holding down AltGr and a letter would print a graphical symbol).
I tried using them, lots of crashing http://sourceforge.net/tracker/index.php?func=detail&aid=887327&grou...
No. Arrows are for moving. Rotation is different and needs different keys.
I disagree (rotation is still moving and I think) using differnt keys is unnecessary.
I think it is advantagous to be able to keep ones hand fixed on the arrow keys and only need to make slight adjustments (Ctrl|Alt|Shift) with the other hand to do all these differnt tasks.
If i can get a working build I will be sure to try using the keys you proposed but using both Alt keys as you have suggested seems like it would be quite awkward.
Inkscape already uses up and down arrows for Nudging, shift+arrow gives a bigger nudge. Inkscape uses Ctrl+Arrows for some sort of Panning/scrolling but I think this is a waste.
Why? I use it all the time. It's very convenient.
I'm not sure if it is this is a good keybinding for panning but it should not be used when there is a selection.
Panning must not depend on whether there is a selection.
I dont understand. Can you explain why?
When something is selected then Ctrl+Arrows could be used for rotating it.
No. Confusing. Panning keys always pan. Rotating keys always rotate. That's the way it should be.
I see it as same keys doing slightly different things when associated with a differnt modifier or in an entirely differnt tool mode. I'll ponder this some more.
I'm thinking maybe also that you cannot have a meaningful 'rotate' when you are in Node Edit mode (as opposed to the standard select mode)
Yes I can. Select a node and press [ or ].
I alway think of the node as being the point specifically, you mean to rotate the bezier spline (i think spline is the word I'm looking for, you know the lines that go throught the node and that you can adjust to change the curve).
Errm I've got more to say but I dont think I'm convincing anyone so I'll respond to your other post and deal with discuss slightly diffent ascpects.
- Alan
On Thu, 2004-01-29 at 18:39, Alan Horkan wrote:
I'm not sure if it is this is a good keybinding for panning but it should not be used when there is a selection.
Panning must not depend on whether there is a selection.
I dont understand. Can you explain why?
Most of Bulia's user interface decisions serve to reduce the amount of "modality" in the interface.
[ ...an exception being the auxiliary toolbar, but that's an extra convenience rather than a requirement to get to most features, and the remaining features are specific to the particular tool. ]
In general usability studies have shown that "modal" interfaces are harmful for usability.
Part of the reason for this is that modality places an increased burden on the user -- they need to maintain a mental model of the internal "state" of the application before they can know what a given action/keypress will do.
[ Visual indications (such as the selection indicators) mitigate this burden a little, but they do not remove it entirely. ]
Modal interfaces also place an additional burden on the user: the user needs to maintain a mental map of the state transitions necessary to return to a state where the desired functionality is available.
At that point, they still need to perform the complex sequence of actions necessary to arrive there.
[ Specifically, unselecting objects in order to pan, only to have to re-select them afterwards, would make the interface inordinately difficult to use. ]
In practice, any sufficiently complex interface will need to have modal elements, but it's important to minimize the modality and avoid making it too fine-grained.
-mental
This is a good architectural/design rationale - it'd be worthwhile if you could add it to either Wiki or the doc/ directory?
Bryce
On Sat, 31 Jan 2004, MenTaLguY wrote:
On Thu, 2004-01-29 at 18:39, Alan Horkan wrote:
I'm not sure if it is this is a good keybinding for panning but it should not be used when there is a selection.
Panning must not depend on whether there is a selection.
I dont understand. Can you explain why?
Most of Bulia's user interface decisions serve to reduce the amount of "modality" in the interface.
[ ...an exception being the auxiliary toolbar, but that's an extra convenience rather than a requirement to get to most features, and the remaining features are specific to the particular tool. ]
In general usability studies have shown that "modal" interfaces are harmful for usability.
Part of the reason for this is that modality places an increased burden on the user -- they need to maintain a mental model of the internal "state" of the application before they can know what a given action/keypress will do.
[ Visual indications (such as the selection indicators) mitigate this burden a little, but they do not remove it entirely. ]
Modal interfaces also place an additional burden on the user: the user needs to maintain a mental map of the state transitions necessary to return to a state where the desired functionality is available.
At that point, they still need to perform the complex sequence of actions necessary to arrive there.
[ Specifically, unselecting objects in order to pan, only to have to re-select them afterwards, would make the interface inordinately difficult to use. ]
In practice, any sufficiently complex interface will need to have modal elements, but it's important to minimize the modality and avoid making it too fine-grained.
-mental
On Sat, 2004-01-31 at 17:37, Bryce Harrington wrote:
This is a good architectural/design rationale - it'd be worthwhile if you could add it to either Wiki or the doc/ directory?
I've added a ModalInterfaces page to the Wiki.
-mental
participants (4)
-
Alan Horkan -
Bryce Harrington -
bulia byak -
MenTaLguY