On Mon, 10 Nov 2003, bulia byak wrote:
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?
Hmm, I'm guessing that my window manager is stealing them for something that doesn't cause obvious effect.
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).
Cool, those are perfect keys for the function. :-)
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.
*Nod* We should also keep this in mind as we rework the dialog to fix some of its other misbehaviors.
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.
Cool, it looks very good. These are going to help power users a lot. Maybe someone will draw up a nice printable cheat sheet?
Zoom and scroll
- on the keypad works for zooming in, but the regular + key doesn't.
I think I fixed this. Please check.
Okay, will check it this evening.
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).
*Nod* Good call. Being able to 'float' between the keys to zoom in and out will be very handy.
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.
It's probably not implemented. I've posted an RFE for it.
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.
We'll need to see what people think of this... If people find themselves accidentally closing the app this way it might get annoying. I think Ctrl-F4 is the more typical shortcut for closing a window, so we might want to consider that. I would imagine this is addressed in the HIG?
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"?
Sorry, yes I 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.
Ah, well that'd explain it. I was fairly perplexed. ;-) Sounds like with some additional thought it can be sorted out.
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.
Gotcha.
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.
Mmm, this'll be nice. I look forward to trying it out.
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 :)
Hehe, touche'. Okay, works for me.
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?
Sort of... But yeah you're right there's probably better ways to address that need than this.
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.
Hmm, I'm not sure, but will see how others think about it. If it doesn't annoy anyone, then no problem, and if it does, well someone will say so. :-)
Bryce