Tool switching

F1 and Ctrl F6 don't seem to do what they're supposed to; all of the rest of the shortcuts worked as documented (both the letter and function key variants).

They work for me, and I have absolutely no idea why these might not work. They're just two shortcuts among others. The only reason may be that the underlying functions do not work, which I did not touch. Is there any diagnostics? Maybe a "make clean" or something would help?

It would be nice to have a shortcut to the Editing Window added (or even better would be keyboard shortcuts to turn grid and snap on/off directly).

Now # toggles grid and | toggles guides, except that toggling guides does not work for some reason (it's disabled in the dialog too).

I noticed that ESC works for many of the dialogs but not all. The export window, for example, didn't respond to Esc.

I will try to see if I can do something about that. It's high priority because the simple keys like arrows and esc must work reliably everywhere.

I've added a TODO section at the bottom of

http://www.inkscape.org/cgi-bin/wiki.pl?KeyboardShortcuts

This and many other ideas are there. Please discuss or add your own! Yemu: your suggestion is there too, edit as appropriate.

Zoom and scroll

• on the keypad works for zooming in, but the regular + key doesn't.

I think I fixed this. Please check.

We probably need a keyboard mapping for "Fit the whole selection into the window". Perhaps one of the number keys to keep with the scheme? Also note that keypad-5 is mapped to "Fit the whole drawing into window", so that could be added to the docs. However, the regular 5 key isn't mapped. Since both regular and keyboard 0 and 1 are mapped, it seems sensible for both 5's to be likewise.

I think the old scheme was not very logical or convenient. Now I did this: 1 is 1:1, 2 is 1:2, 3 is selection, 4 is drawing, 5 is page. This makes it a more logical sequence (assuming drawing is smaller than page).

Mapping Ctrl-z and Ctrl-shift-z to the opposite actions is kind of slick; makes it easy to quickly scroll up and down through the transaction log. And having Ctrl-y mapped to the redo makes sense since that's a commonly expected mapping.

I wonder if for perfect balance, Ctrl-shft-y should be mapped to 'undo'?

Why not.

Ctrl-w 'close window' only seems to work when the mouse is hovering over the window when the window system is set to click-to-follow mode.

Yes, it's a local binding for a canvas window and perhaps it does not work when mouse is away. It cannot be made global.

I'm not sure what Ctrl-shft-n does, but it didn't seem to work for me.

No traces in the code. Removed.

Ctrl-shft-p did not pop up the print preview

This one is enabled, but the function does not work (from menu, too). Someone needs to find out.

Ctrl-shft-s did not pop up the save file as box

Should work now.

Ctrl-q only exits if the cursor is in the editing window; it doesn't work when used over the toolbox nor if no document is loaded.

Fixed by making it global.

Selector tool shortcuts

The arrow keys all worked as advertised - that's going to be a really nice enhancement. I noticed though that the keyboard arrows did not always work - the kbd up and down are mapped to zoom up/down, and the rt and left don't have actions. The kbd alt-arrows don't have action. All kbd-arrows with the shift or shift-alt modifiers work as documented.

By "keyboard", do you mean "keypad"?

If so, that's strange. But after some thinking I remembered that some time ago I patched my X keyboard configuration so that keypad arrows _always_ produce arrows, with or without shift. (I can give details of the patch if someone is interested.) Without that patch, the KP arrows were arrows without shift and digits with shift, and vice versa if numlock is on. I never use KP digits but I like to use KP arrows with and without shift (for selecting) in Emacs, hence the patch. Now, if the original configuration is standard (it was by default on Mandrake), this means most people won't be able to use KP arrows with shift at all, unless they reconfigure X like I did. (Or they only can use KP arrows with shift but cannot without, if numlock is on.) I personally find this situation a bit weird, and we perhaps need to talk to an expert in X keyboard to see if there's another workaround. The idea to reconfigure XKB was the first to come to my mind and it worked for me, so I never researched the matter any deeper since that. We'll also need to find out how this is done outside of linux.

Maybe we need to check for, e.g., GDK_KP_4 instead of (or in addition to) Shift with KP_Left? I will try this but I'll need someone else to test it on a standard linux and on other platforms.

As for "kbd up and down are mapped to zoom up/down", no - it's just that the zoom value field in the bottom right corner grabs focus (very annoying!). I'll see if I can tame it somehow.

Ctrl-a 'select-all' also works but needs adding to the documentation.

Done. I also made this local to the select tool, as it not always makes sense (and may be confusing) in other tools.

I'm wondering about ctrl-d though - in emacs and probably other apps it's mapped to the same function as the DEL key, whereas here it duplicates the selected item.

In Xara, it's duplication as well, and I believe in Corel Draw too. Those are better matches for us than Emacs :)

Home/end/pgup/pgdn all work. The keyboard versions of those aren't mapped similarly. I'm undecided if they should though; could be too much functionality for the keyboard.

For consistency, I enabled the KP keys too.

I had a thought... What if we made the keyboard mappings not do any document changes, so that it's read only? What I'm thinking is that being able to rely on the keyboard as a read-only navigation interface would be handy since they could navigate around without having to worry about accidentally hitting the wrong key and fussing up the document.

I think it's too much to change, there are already many shortcuts that modify the document. Instead, isn't there a slideshow mode that only displays SVG without editing?

Ctrl-g and ctrl-shft-g work for group/ungroup. Ctrl-u does ungroup; perhaps Ctrl-shft-u should group?

Why not.

The mouse modifiers for stretch, rotate, skew, etc. all checked out. Are some of these new or had I just not known about them before? I am going to find Ctrl-move and alt-transform quite useful. :-)

No, I did not touch these yet (but I plan to). They are all from Sodipodi.

Node edit tool shortcuts

In editing mode, the regular arrows all worked as documented. Nice. The keyboard keys didn't do anything though.

See above for keypad ideas.

I'm wondering if in node-edit mode it might be more useful for the keyboard arrowkeys to be left to view commands like moving the view window, zooming, etc. Hmm, maybe we need a stronger defined concept of what the keyboard does - either always precisely map to what the regular arrow, paging, etc. keys do, or map to some other useful mode like view-window control?

You can zoom and pan in node editor, no problem. No need to deassign arrow keys. My concept is simple: everything must be consistent. If arrows move selection in selector, they must do the same in all other tools where "selection" makes sense. Ctrl-arrows pan canvas, and they do so everywhere.

You've got shift-k and shift-l listed twice.

Fixed.

One thing that may be a bit awkward is with the unmodified keys, if you happen to on the canvas instead of precisely over a node, the key can cause you to leave node-edit mode and activate some other function. The s key, for instance, ends up selecting the object, and the b key activates the create-curve function.

I thought about that and wanted to remove these unmodified keys to alt-keys or digits. But when I actually tried this, I found that they affect active node, and active node only exists when you are dragging it with your mouse. So psychologically, these are not "unmodified keys"; rather, they are "mousedrag+letter" keys and are unlikely to be confused with simple "letter" keys.

The rest will have to wait until tomorrow...