Currently Inkscape uses Alt-Click for various things (select-under, randomize star, etc.) However, generally this shortcut is taken by the desktop environments. In fact we have a bug in our tracker and in Ubuntu's tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=1250110&gro...
It is possible for the user to recover this shortcut for Inkscape by disabling it in the desktop environment's configuration settings, but this has the obvious downside of disallowing the shortcut for other programs beyond Inkscape.
In playing around with it a little, I notice that Alt-Ctrl-LeftClick appears to produce the same behavior as Alt-LeftClick. Since Alt-Ctrl-LeftClick is not taken by the desktop environment, there is no conflict.
Thus it would seem that we could address the bug easily without any code change to Inkscape, by simply altering the documentation to indicate use of Alt-Ctrl-LeftClick instead of Alt-LeftClick. For users who prefer the Alt-LeftClick behavior, that will remain working so no functionality is lost.
What do others think of this approach?
Bryce
On 1/4/07, Bryce Harrington <bryce@...961...> wrote:
In playing around with it a little, I notice that Alt-Ctrl-LeftClick appears to produce the same behavior as Alt-LeftClick.
Nope. In Selector, the Ctrl has the meaning of "select in groups". So while Alt+click does "select under", the Ctrl+Alt+click does "select under, disregarding grouping". Which is a different behavior if you have groups. See http://inkscape.org/doc/keys.html.
On Fri, Jan 05, 2007 at 03:29:08AM -0400, bulia byak wrote:
On 1/4/07, Bryce Harrington <bryce@...961...> wrote:
In playing around with it a little, I notice that Alt-Ctrl-LeftClick appears to produce the same behavior as Alt-LeftClick.
Nope. In Selector, the Ctrl has the meaning of "select in groups". So while Alt+click does "select under", the Ctrl+Alt+click does "select under, disregarding grouping". Which is a different behavior if you have groups. See http://inkscape.org/doc/keys.html.
But that is the only exception I found. All the rest of the uses of Alt+click seem to be the same as Ctrl+Alt+click.
So aside from this one, why not switch the documentation for all the remaining cases?
Bryce
On 1/5/07, Bryce Harrington <bryce@...961...> wrote:
But that is the only exception I found. All the rest of the uses of Alt+click seem to be the same as Ctrl+Alt+click.
Not really. Two more examples: Dragging in selector: Alt+drag - move selected, Ctrl+Alt+drag - move selected restricting to hor/vert (because with dragging, Ctrl has the semantics of restricting to hor/vert). Selecting in Node tool: Alt+click - select object under (same as in Selector), Ctrl+Alt+click - create/delete node.
And in general, even if it were possible, I don't like this idea because it will make it even more difficult to remember the shortcuts by further destroying the one-to-one correspondence between modifiers and semantics. We already violate this principle in some cases, but at least within a single tool, we try to stay consistent.
On Fri, Jan 05, 2007 at 06:22:43AM -0400, bulia byak wrote:
On 1/5/07, Bryce Harrington <bryce@...961...> wrote:
But that is the only exception I found. All the rest of the uses of Alt+click seem to be the same as Ctrl+Alt+click.
Not really. Two more examples: Dragging in selector: Alt+drag - move selected, Ctrl+Alt+drag - move selected restricting to hor/vert (because with dragging, Ctrl has the semantics of restricting to hor/vert). Selecting in Node tool: Alt+click - select object under (same as in Selector), Ctrl+Alt+click - create/delete node.
And in general, even if it were possible, I don't like this idea because it will make it even more difficult to remember the shortcuts by further destroying the one-to-one correspondence between modifiers and semantics. We already violate this principle in some cases, but at least within a single tool, we try to stay consistent.
However note that I am not suggesting to *remove* the Alt+Click behavior, but rather to simply document it as Ctrl+Alt+Click. This does not in any way "destroy" the correspondence here; it merely makes the functionality accessible to the vast bulk users who won't modify their desktop environment shortcut settings.
I know that you feel this is conceptually unclean, however at the same time you must recognize that using a shortcut that GNOME and KDE both already have locked up is untenable. Despite the eligance of the one-to-one correspondance, the fact is that the shortcut isn't realistically available for use.
Again, recognize this proposal is not to make any functional change to inkscape; merely to document Inkscape in a way that enables ordinary users to access useful functionality that is already mapped to keys they have available to them without requiring any remapping of their desktop environment shortcut keys.
Bryce
On 1/5/07, Bryce Harrington <bryce@...961...> wrote:
However note that I am not suggesting to *remove* the Alt+Click behavior, but rather to simply document it as Ctrl+Alt+Click.
I understand that. What I'm saying is that this documenting is likely to damage the consistency in users' _minds_, not necessarily in the program itself.
I know that you feel this is conceptually unclean, however at the same time you must recognize that using a shortcut that GNOME and KDE both already have locked up is untenable. Despite the eligance of the one-to-one correspondance, the fact is that the shortcut isn't realistically available for use.
OK, can you name a specific shortcut that can be redocumented from Alt+ to Ctrl+Alt without clashing with any existing shortcuts?
On Fri, Jan 05, 2007 at 07:05:34AM -0400, bulia byak wrote:
On 1/5/07, Bryce Harrington <bryce@...961...> wrote:
However note that I am not suggesting to *remove* the Alt+Click behavior, but rather to simply document it as Ctrl+Alt+Click.
I understand that. What I'm saying is that this documenting is likely to damage the consistency in users' _minds_, not necessarily in the program itself.
Yes, I hear you, but I think the damage potential is negligible compared with not being able to use the functionality at all.
I would in fact argue that if the user runs into shortcuts that overlap with their window manager, it will cause them to distrust the entire keyboard mapping - if one functionality is mismatched, then maybe others are mismatched? This causes them to lose trust in the reliability and consistency of the keyboard shortcuts as a whole.
I know that you feel this is conceptually unclean, however at the same time you must recognize that using a shortcut that GNOME and KDE both already have locked up is untenable. Despite the eligance of the one-to-one correspondance, the fact is that the shortcut isn't realistically available for use.
OK, can you name a specific shortcut that can be redocumented from Alt+ to Ctrl+Alt without clashing with any existing shortcuts?
Yes, here is a patch with the changes I would propose. I've tested them and things seem okay on my system, although I might have missed one or two.
This only deals with Alt+Click, not Alt+Drag. Also, I did not modify the group selection shortcuts, but adjusted the comment a bit.
Bryce
Index: keys.xml =================================================================== --- keys.xml (revision 13582) +++ keys.xml (working copy) @@ -463,7 +463,10 @@ <mouse><key><alt/><left-click/></key> <action>select under</action></mouse> <note>Alt+click selects the object at click point which is beneath (in z-order) the lowest selected object at click point.</note> <note>If the bottom object is reached, Alt+click again selects the top object. So, several Alt+clicks cycle through z-order stack at point.</note> -<note>On Linux, Alt+click and Alt+drag may be reserved by the window manager. Reconfigure it so you can use them in Inkscape.</note> +<note>On Linux, Alt+click and Alt+drag may be reserved by the window +manager. Ctrl+Alt+click produces similar behavior and can be </note> +<note>used instead, or if you'd prefer, reconfigure your window manager +so you can use them in Inkscape.</note> <mouse><key><shift/><alt/><left-click/></key> <action>toggle under</action></mouse> <mouse><key><ctrl/><alt/><left-click/></key> <action>select under, in groups</action></mouse> <mouse><key><shift/><ctrl/><alt/><left-click/></key> <action>toggle under, in groups</action></mouse> @@ -697,7 +700,7 @@ <group> <title>Mouse select: objects</title> <mouse><key><left-click/></key> <action>click a non-selected object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse> <mouse><key><shift/><left-click/></key> <action>toggle selection</action></mouse> <note>These work the same as in Selector. The nodes or handles of the single selected object become editable.</note> </group> @@ -790,7 +793,7 @@ <group> <title>Editing</title> <mouse><key><left-click/></key> <action>click an object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse> <mouse><key><shift/><left-click/></key> <action>toggle selection</action></mouse> <mouse><key><left-drag/></key> <action>drag a handle to resize or round corners</action></mouse> <note>Initially, the two rounding handles are in the top right corner; two resize handles are in top left and bottom right corners.</note> @@ -815,7 +818,7 @@ <group> <title>Editing</title> <mouse><key><left-click/></key> <action>click an object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse> <mouse><key><shift/><left-click/></key> <action>toggle selection</action></mouse> <mouse><key><left-drag/></key> <action>drag a handle to resize, make arc or segment</action></mouse> <note>Initially, the two arc/segment handles are in the rightmost point; two resize handles are at the topmost and leftmost points.</note> @@ -837,14 +840,14 @@ <group> <title>Editing</title> <mouse><key><left-click/></key> <action>click an object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse> <mouse><key><shift/><left-click/></key> <action>toggle selection</action></mouse> <mouse><key><left-drag/></key> <action>drag a handle to vary the star shape</action></mouse> <mouse><key><ctrl/><left-drag/></key> <action>keep star rays radial (no skew)</action></mouse> <mouse><key><shift/><left-drag/></key> <action>round the star</action></mouse> <mouse><key><shift/><left-click/></key> <action>remove rounding</action></mouse> <mouse><key><alt/><left-drag/></key> <action>randomize the star</action></mouse> -<mouse><key><alt/><left-click/></key> <action>remove randomization</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>remove randomization</action></mouse> <keys><key><misc f="Esc"/></key> <action>deselect</action></keys> </group> </section> @@ -859,12 +862,12 @@ <group> <title>Editing</title> <mouse><key><left-click/></key> <action>click an object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse> <mouse><key><shift/><left-click/></key> <action>toggle selection</action></mouse> <mouse><key><left-drag/></key> <action>roll/unroll from inside (inner handle)</action></mouse> <note>Dragging the inner handle adjusts the "inner radius" parameter.</note> <mouse><key><alt/><left-drag/></key> <action>converge/diverge (inner handle)</action></mouse> -<mouse><key><alt/><left-click/></key> <action>reset divergence (inner handle)</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>reset divergence (inner handle)</action></mouse> <note>Vertical Alt+drag of the inner handle adjusts the "divergence" parameter, Alt+click resets it to 1.</note> <mouse><key><shift/><left-click/></key> <action>zero inner radius (inner handle)</action></mouse> <note>Shift+click on inner handle makes the spiral start from the center.</note> @@ -1002,7 +1005,7 @@ <group> <title>Mouse select</title> <mouse><key><left-click/></key> <action>click an object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse> <mouse><key><shift/><left-click/></key> <action>toggle selection</action></mouse> </group>
@@ -1017,7 +1020,7 @@ <mouse><key><shift/><left-drag/></key> <action>average stroke color</action></mouse> <note>Click applies the color under cursor to the current selection. Dragging a radius calculates the average color of a circular area.</note> <note>If a gradient handle (in Gradient tool) is selected, it gets the color instead of the entire object.</note> -<mouse><key><alt/><left-click/></key><key><alt/><left-drag/></key> <action>pick inverse color</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key><key><ctrl/><alt/><left-drag/></key> <action>pick inverse color</action></mouse> <note>If Alt is pressed, picking color (with or without Shift, by click or by drag) picks the inverse of the color.</note> <keys><key><ctrl/>C</key> <action>copy color</action></keys> <note>This copies the color under cursor to the system clipboard, as text in RRGGBBAA format (8 hex digits).</note>
On 1/5/07, Bryce Harrington <bryce@...961...> wrote:
-<note>On Linux, Alt+click and Alt+drag may be reserved by the window manager. Reconfigure it so you can use them in Inkscape.</note> +<note>On Linux, Alt+click and Alt+drag may be reserved by the window +manager. Ctrl+Alt+click produces similar behavior and can be </note> +<note>used instead, or if you'd prefer, reconfigure your window manager +so you can use them in Inkscape.</note>
Why the vague "similar" when you can be specific in what ctrl+alt+click does exactly and how it's different? By the way the complete description of ctrl+alt+click is just two lines below. Also, I think that if the user was motivated enough to consult the documentation, we should give him the correct solution (reconfigure WM) _first_ and the weak alternative second, not vice versa as you did.
So, instead I would add in parentheses at the end of the comment: "(Sometimes you can also use Ctrl+Alt+click (select under in groups) with the same effect.)"
Although to my taste, this would be rather confusing and therefore would do more harm than good.
@@ -697,7 +700,7 @@
<group> <title>Mouse select: objects</title> <mouse><key><left-click/></key> <action>click a non-selected object to select</action></mouse> -<mouse><key><alt/><left-click/></key> <action>select under</action></mouse> +<mouse><key><ctrl/><alt/><left-click/></key> <action>select under</action></mouse>
That won't do. I asked you to only change those cases where there's no conflict, and I even listed this specific one as an example of conflict. Ctrl+Alt+click does a completely different thing in Node tool.
Please review your patch with this requirement in mind. You'll need to search the doc and/or test the program to make sure that each Ctrl+Alt+click you propose does exactly the same as the corresponding Alt+click. If it does not, we'll have to leave this specific Alt+click alone.
Also, I don't think I'll agree to _replacing_ Alt+click by Ctrl+Alt+click. Instead, just list Ctrl+Alt+click as a second alternative shortcut, as is done, for example, for "zoom in" which lists both middle click and Ctrl+right click in the same line as alternatives. We can also add a comment in such cases pointing out that if Ctrl+Alt+click may work in some Linux systems where Alt+click does not.
On Fri, Jan 05, 2007 at 03:01:15PM -0500, bulia byak wrote:
On 1/5/07, Bryce Harrington <bryce@...961...> wrote: So, instead I would add in parentheses at the end of the comment: "(Sometimes you can also use Ctrl+Alt+click (select under in groups) with the same effect.)" Instead, just list Ctrl+Alt+click as a second alternative shortcut, as is done, for example, for "zoom in" which lists both middle click and Ctrl+right click in the same line as alternatives. We can also add a comment in such cases pointing out that if Ctrl+Alt+click may work in some Linux systems where Alt+click does not.
This is done. Also, I added a blurb in the basic tutorial that if Alt-click doesn't work for the user, that they should fix their window manager to use Meta- instead of Alt- if possible. I suspect that is the root source of the confusion here, so that's probably where the fix is really needed. Can someone update the tutorials? The make-svg script just produces a "Exception in thread main" error for me.
Bryce
# from Bryce Harrington # on Friday 05 January 2007 02:45 am:
using a shortcut that GNOME and KDE both already have locked up is untenable. Despite the eligance of the one-to-one correspondance, the fact is that the shortcut isn't realistically available for use.
IMNSHO, the "alt+drag to move window" wm shortcut is a very useless waste of what would otherwise be a very useful application shortcut. I suspect that nobody running a lot of graphics applications has left it at the default, because if you're doing very much with graphics, you need those modifiers for the mouse. I suppose if one deals with nothing but text, moving windows is the most mouse-intensive task.
Let them add more bucky bits to the kde setting if they feel that shuffling windows around is such a critical task. Sure, it is a little severe to claim ownership of this shortcut, but wasn't it a little audacious for the WM's to claim it globally?
I'm curious how many users actually utilize that WM feature. Isn't the case for most users simply that they'll have to disable the default to get the window manager out of their way? (BTW, "out of the way" is where the WM is supposed to be.)
--Eric
On Fri, Jan 05, 2007 at 10:39:56AM -0800, Eric Wilhelm wrote:
IMNSHO, the "alt+drag to move window" wm shortcut is a very useless waste of what would otherwise be a very useful application shortcut.
Could be, but given that both GNOME and KDE have this shortcut set as one of the defaults, we are left having to deal with reality. There seem to be three choices: a) Maintain our current approach of insisting users remap their DE shortcuts, b) convince KDE and GNOME to permit applications to have this shortcut, or c) adjust what we do to work around the limitation.
Option (a) imposes usability harm on users; users have been sending in bug reports about this, so I believe it to be an imperfect strategy. Option (b) is the ideal solution, however it would be extremely difficult to convince them to stop using Alt+Click and Alt+Drag, and only somewhat less so to convince them to implement overloadable shortcuts (which would be the perfect solution); in either case, we'd still be faced with waiting at least a year or two before the changed DE became widespread enough that we could consider it fixed.
Thus option (c) is best here. It is not much work on our part, it addresses the issue, makes life easier on users, and leaves open option b if it becomes possible some day.
I'm curious how many users actually utilize that WM feature.
I don't know if any data exists to say how many users use this feature. However, speaking only for myself, I have found it useful on multiple occasions (I have a multi-head setup, and am frequently moving windows around to get them onto my main monitor). Despite knowing about this conflict for years, I still keep Alt+Click and Alt+Drag mapped for the WM.
However, this is sort of beside the point - we can certainly convince ourselves that this is not a worthwhile WM feature, but it won't change the fact that it's still not available to us by default. You could try making this argument to Xorg, GNOME, KDE, and the various distros, but honestly I suspect the response would be that this Inkscape need simply isn't important enough to them to warrant considering changing it.
Isn't the case for most users simply that they'll have to disable the default to get the window manager out of their way?
Exactly. I don't know if I would call it 'simply' though; it took me a good bit of searching to find exactly where in KDE to disable it (it's buried on a secondary tab of). I imagine most users won't be bothered to do this. Besides, why cause them to go to this trouble when the functionality is already available through another shortcut already hooked up, that doesn't conflict?
Bryce
Bryce Harrington wrote:
On Fri, Jan 05, 2007 at 10:39:56AM -0800, Eric Wilhelm wrote:
IMNSHO, the "alt+drag to move window" wm shortcut is a very useless waste of what would otherwise be a very useful application shortcut. I'm curious how many users actually utilize that WM feature.
I have known people who have used and loved it. On less than polished WMs it is extremely useful in order to retrieve windows that have wanderered off the top of the screen.
Could be, but given that both GNOME and KDE have this shortcut set as one of the defaults, we are left having to deal with reality. There seem to be three choices: a) Maintain our current approach of insisting users remap their DE shortcuts, b) convince KDE and GNOME to permit applications to have this shortcut, or c) adjust what we do to work around the limitation.
d) Try to disable the shortcuts while Inkscape is running. Sounds bizarre but it's similar to video players disabling the screensaver or whatever. Might be achievable with a bit of hackery. KWin offers a DCOP function to reload its configuration and it's possible that Metacity will offer something over D-Bus, or just signalling the process.
This wouldn't necessarily need to happen inside Inkscape code; it could just be a Bash wrapper for Inkscape, provided to packagers.
Compiz and Beryl make Inkscape unusable anway, unless a handful of effects and key bindings are disabled.
I don't know if any data exists to say how many users use this feature. However, speaking only for myself, I have found it useful on multiple occasions (I have a multi-head setup, and am frequently moving windows around to get them onto my main monitor). Despite knowing about this conflict for years, I still keep Alt+Click and Alt+Drag mapped for the WM.
That's ludicrous assuming you're a competent Inkscape user.
However, this is sort of beside the point - we can certainly convince ourselves that this is not a worthwhile WM feature, but it won't change the fact that it's still not available to us by default. You could try making this argument to Xorg, GNOME, KDE, and the various distros, but honestly I suspect the response would be that this Inkscape need simply isn't important enough to them to warrant considering changing it.
The argument doesn't just concern Inkscape on Linux. It ties in to Windows users migrating from a system that doesn't have this binding and where it is routine to use all available modifiers for mouse ops in applications, versus a system where this is a throwback to a time when GUI applications on X were neither complex or cross-platform.
The place to take this up would be freedesktop.org anyway.
Isn't the case for most users simply that they'll have to disable the default to get the window manager out of their way?
Exactly. I don't know if I would call it 'simply' though; it took me a good bit of searching to find exactly where in KDE to disable it (it's buried on a secondary tab of). I imagine most users won't be bothered to do this. Besides, why cause them to go to this trouble when the functionality is already available through another shortcut already hooked up, that doesn't conflict?
Document how to disable the Alt+ keybindings?
Another option is to choose different keybindings in Inkscape. I fear that this would involve toggle keys for the various modifier options. But modal interfaces are considered extremely bad news.
Dan
Daniel Pope wrote:
Bryce Harrington wrote:
On Fri, Jan 05, 2007 at 10:39:56AM -0800, Eric Wilhelm wrote:
IMNSHO, the "alt+drag to move window" wm shortcut is a very useless waste of what would otherwise be a very useful application shortcut. I'm curious how many users actually utilize that WM feature.
I have known people who have used and loved it. On less than polished WMs it is extremely useful in order to retrieve windows that have wanderered off the top of the screen.
On all X11 systems I use I remap the Alt-<something> keybindings of KDE to Super-<something>, the Super- modifier being mapped to the otherwise unused windows key. It's been a very long time since any common keyboard has come without the Windows key. To my mind it makes much more sense to use a key with a windows symbol for window management tasks than Alt-.
My preference would be to persuade developers of windows managers to use this key and leave Alt- free for productive use in applications.
Isn't the case for most users simply that they'll have to disable the default to get the window manager out of their way?
Exactly. I don't know if I would call it 'simply' though; it took me a good bit of searching to find exactly where in KDE to disable it (it's buried on a secondary tab of). I imagine most users won't be bothered to do this. Besides, why cause them to go to this trouble when the functionality is already available through another shortcut already hooked up, that doesn't conflict?
Document how to disable the Alt+ keybindings?
Another option is to choose different keybindings in Inkscape. I fear that this would involve toggle keys for the various modifier options. But modal interfaces are considered extremely bad news.
An option might be to map the Alt- modifiers to Alt- and Win- variants. Those in MS windows would use Alt, those in linux could use either Alt- or Win- whichever their window manager doesn't steal (I'm not quite sure about Mac users they seem to have strange keyboards). It would be easy to document with a simple note to linux users suggesting they try the Win- key if Alt- is taken.
John
John Pybus wrote:
Daniel Pope wrote:
Bryce Harrington wrote:
On Fri, Jan 05, 2007 at 10:39:56AM -0800, Eric Wilhelm wrote:
IMNSHO, the "alt+drag to move window" wm shortcut is a very useless waste of what would otherwise be a very useful application shortcut. I'm curious how many users actually utilize that WM feature.
I have known people who have used and loved it. On less than polished WMs it is extremely useful in order to retrieve windows that have wanderered off the top of the screen.
On all X11 systems I use I remap the Alt-<something> keybindings of KDE to Super-<something>, the Super- modifier being mapped to the otherwise unused windows key. It's been a very long time since any common keyboard has come without the Windows key. To my mind it makes much more sense to use a key with a windows symbol for window management tasks than Alt-.
My preference would be to persuade developers of windows managers to use this key and leave Alt- free for productive use in applications.
I am completely with you. The first thing I do on all my linux boxes is change the window managers options so the windows (super) key is used instead of Alt because it makes sense. Windows moves windows.
I wonder if anyone has tried persuading the wm devs on this.
-Josh
participants (7)
-
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
Daniel Pope -
Eric Wilhelm -
John Pybus -
Joshua A. Andler