>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
Thanks for reporting, that crash is now fixed in CVS.
> > No. Arrows are for moving. Rotation is different and needs different
>I disagree (rotation is still moving and I think) using differnt keys is
No. It's a very different kind of moving. If only because moving has four
directions and rotation only two (as I wrote you before). You cannot
unambiguously map rotation directions to (some of the) four arrows. And
finally, arrows are already so busy with different kinds of moving/panning
that adding rotation to them would produce a total mess. Nobody will be able
to remember those shortcuts.
>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.
It's a bit awkward physically, but it's very easy mentally. It's easy to
understand the logic behind these shortcuts and therefore to remember them.
Try to invent another system where you can scale/rotate both handles or any
single one of them, with two different speeds. Without using left/right alt
trick, these keys will likely occupy half of your keyboard and will be
impossible to remember.
> > Panning must not depend on whether there is a selection.
>I dont understand. Can you explain why?
Because I may want to pan regardless of any selection, of course!
> > >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
Not spline, but the control handles of the bezier attached to the node.
MSN 8 with e-mail virus protection service: 2 months FREE*
>I've been reading the KeyboardShortcutsToDo document in Wiki
>::(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
Panning must not depend on whether there is a selection.
> When something is selected then Ctrl+Arrows could be used for
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
>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 ].
>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
>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
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.
>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
None of the vector editors I know uses pgup/pgdn for panning canvas. It's
just a foreign concept for a two-dimensional one-page canvas. How would you
define the "page" to scroll if what you have before you is just one page?
> > "Tools" is vague. "Dialogs" is exactly what this menu contains. I see no
> > reason for a change.
>Consistancey with about a Zillion applications ...
You can talk about consistency in naming when the functions are similar.
What other apps call "tools" is different. E.g. Illustrator has a similar
menu used to open various dialogs, but it's called View, not Tools. (And
View is obviously more vague and confusing than Dialogs.)
> > See KeyboardProfiles - if you care about Illustrator, plan a profile as
> > described on that page. I promise to implement loading keys from a file
> > 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.
You're welcome. Just don't forget to consult (and test) the current Inkscape
shortcuts, and make sure your proposal does not infringe on (or gracefully
resolves) other shortcuts - because by now, a lot of keys are already taken.
>Lots of new and unique keybindings
>is the worst of all worlds.
Sorry but to me, lots of convenient shortcuts are what matters most, and
their consistency with other apps is secondary. That's what keyboard
profiles are for. (See Wiki.) Especially given that we now have quite a few
shortcuts for which other apps have no equivalent at all. For example
Illustrator cannot move by single pixel, cannot scale or rotate by keyboard,
cannot edit nodes by keyboard - I find it very frustrating when I have to
work in Illustrator.
> > File > Import?
>That was among the things I tried but that didn't work.
I will test.
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>So what do you think then about just adding the keyboard shortcuts as
>this type of tutorial, with the key graphics I created sometime ago.
Where are these graphics? Can you send them to me?
>NOTE: Basically, we could even have an "open template," where we could
>have sets of template svgs of different documents where people could
>select like--standard icon, or letter, or A4, or stationary, or a style
Yes, but that's another matter. I'm now working on Help menu.
>Hmmm...what do you recommend now for the keyboard shortcuts/manpage.
Not sure about manpage (maybe we can live without it in the Help menu, now
that we have a tutorial), but I'm working on shortcuts as an SVG reference
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
>Is it part of the plan that the item "Dialogs, Tool Options" be merged
>into the secondary toolbar? I think I recall it being mentioned.
Yes. It's in the plans.
> > > > See KeyboardProfiles - if you care about Illustrator, plan a profile
> > > > described on that page. I promise to implement loading keys from a
> > >as soon as we have two complete profiles of different mainstream
>If you clarify what exactly you mean by "complete profile" I might be able
>to do something, I'm pretty sure the Adobe Illustrator documentation lists
>all the keybindings.
See http://inkscape.org/cgi-bin/wiki.pl?KeyboardProfiles, section "What is
to be done". Basically you need to compile a list of keybindings with a
classification of their applicability to Inkscape.
>I would hope that you will remain flexible and not reject changes just
>because Inkscape has been doing something a certain way before (of course
>when Inkscape has been around longer I'd accept this arguement
>View, Grid #" is a bad keybinding for Americans. if i recall correctly
># is Shift+3 on an American keyboard.
What's bad with it being easy to remember? Can you find any key that looks
more like a grid than #?
>Also the label should probably be
>changed to Show Grid (and similarly Show Rulers and Show Scrollbars).
Yes, but then it must be Show/Hide, which is bulky. The menu needs to be
redone so that the labels are dynamic, e.g. showing "Show grid" when no grid
and "Hide grid" otherwise. Until then, let it be just "Grid".
>I'd also recommend avoiding single letter keybindings for most things
>except the tools (but I wont be surprised if you dont think the
>Function keys should be changed either).
I don't know - that depends on the strength of your arguments :)
>For similar reasons I'm not sure about the keybindings for
>Next Zoom Shift+'
>Prev Zoom '
Your proposal being?
>(abbreviations definately not allowed!)
You mean, in the menu? I think we can take an exception, Prev is easy to
understand next to Next, and they line up nicely.
>but I find the whole idea a bit odd, it is like a seperate undo history
>for Zoom which is not something I've seen before.
Xara has a "previous zoom" command which is very convenient. Unfortunately
it only takes you back to previous zoom and not further, which is why I
decided to carry the idea further and implement a complete zoom history. I
now use it all the time.
>Group and Ungroup use the shortcuts Ctrl+G and Ctrl+U respectively which
>are reasonable. But given the shortage of avialable keys, the Gnome HIG,
>and the keybindings used by Adobe Illustrator I would suggest
>you consider changing it to Ctrl+Shift+G for Ungroup.
This might make sense, if you propose a compelling function for Ctrl+U.
Otherwise, why disrupt? Ctrl+Shift+G for Ungroup works already exactly as
>The Gnome HIG recommends the principle of using the Shifted version of a
>keybinding for the inverse or for related tasks.
>"Use Shift-Ctrl-letter for functions that reverse or extend another
>function. For example, Ctrl-Z and Shift-Ctrl-Z for Undo and Redo."
We support exactly that.
>Getting distracted again I notice Inkscape has "Clear All" which is
>grouped beside select all and I mistakenly thought it meant clear
>the selection i.e. "Select None".
That's a good point. I think makes sense indeed to replace "clear all" with
a "deselect" command. Adding that to TODO.
> > > > File > Import?
>Tried agian with a more recent build from today and I still cannot import
>any images (tried jpegs png and bitmaps).
Please submit a bug with detailed description.
>For all my complaining I really do like Inkscape and I appreciate all the
>work you all put into it. We sometimes forget to thank people for
>all their great work so, "Thanks for the software".
You're welcome :)
Add photos to your messages with MSN 8. Get 2 months FREE*.
I also make a motion to remove the GTK color that makes the fill/stroke
palette to massive in the release. Agree? Disagree? Obviously, we will
add back in once the custom gtk color wheel is finished.
Jonathan Phillips <jon@...15...>
> > - on my KDE 3.14, fullscreen only works properly when there are no
> > other maximized windows. If there's a maximized window and an Inkscape
> > window over it, then calling fullscreen results in unending flashing
> > of these two windows - this can only be stopped by killing
> > Inkscape. Anyone else having this problem?
>This is a window manager related issue depending on WM_HINTS etc. (Xlib)
>It works in sawfish, which is more tied in with gtk. I'll see if I can
>it somehow or change the X properties of a window.
Now that I've checked, the fullscreen in Gimp 1.3.23 exhibits the same
behavior. So, please try to tweak what you can, but it may well be unfixable
with the current versions of GTK or KDE. Hopefully this will be resolved
sometime in the future...
> > - when I open new document windows from a fullscreen window, they are
> > sometimes on top of it but sometimes they sink under the fullscreen
> > window (can't guess what is the algorithm here).
>Hm, no idea, could it be window focus rules ?
Maybe. I'll try to investigate.
Thanks for the contribution, please keep up the good work! :)
Protect your PC - get McAfee.com VirusScan Online
Fullscreen rocks! I think we should add a toggle switch to the bottom of
the doc. window next to the zoom toggle, possibly to the left of it.
When you get into hardcore design work, it is good to have a switch to
Great WORK jceuppan...did we give him dev. access yet?
Jonathan Phillips <jon@...15...>
>my attempt is in cvs under doc/default.svg. I'd be most grateful if
>someone with some time and skill could polish it up.
Good idea, it should be added to the Help menu when it's ready (it's even
simpler than adding a keyboard shortcuts page - no need to run a browser).
Start it with how to scroll/zoom around and how to select things. Then,
creating basic shapes; transforms with selector; changing fill and stroke;
opening/saving; node tool; text tool; etc. The order is approximate, of
>It would also be good to work out how to make the tutorial start at a
>reasonable size, near the top.
Just save it, and next time it will come up with this zoom/view/window size.
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*.