alert the user about X11.app stealing some modifier keys

Use Alt-drag to drag the selection without reselecting anything

Crufty solution. The user expectation when dragging within an existing selection is to manipulate that selection. Further, it traps the expected behavior of option(alt)-drag when a selection overlaps the current view.

You mean 'my expectation', right? People come to Inkscape with a wide
range of UI history/prejudices ;)

Anyhow, there's one additional aspect of this I'd like to have cleared
up while we have Bulia's attention. Using your same example file, if I
group the two blue rectangles before dragging, then I don't need to
hold Alt to get the behavior you request. They are still visually
below the pink squiggle, but I can now drag the 'lower' group. Is this
expected behavior?

On Jan 31, 2008 3:21 PM, Matt Rasmussen <email address hidden> wrote:
> Crufty solution. The user expectation when dragging within an existing
> selection is to manipulate that selection. Further, it traps the
> expected behavior of option(alt)-drag when a selection overlaps the
> current view.
>
>
> --
> Marquee select ignored if there is an object in the foreground
> https://bugs.launchpad.net/bugs/187531
> You received this bug notification because you are a member of Inkscape
> Bug Team, which is the bug contact for Inkscape.
>

> The user expectation when dragging within an existing
selection is to manipulate that selection.

Very true. Except that, you know, Inkscape has no magic way to peek into your head and know whether your expectation was to move the selected blue things or to forget about them and push the pink thing. It could be either. For consistency, it always assumes that when you click and drag something, you want to select and drag that something. If it's not the case, use Alt. Simple and logical.

> Further, it traps the expected behavior of option(alt)-drag when a selection overlaps the current view.

This comment I don't understand.

> Using your same example file, if I
group the two blue rectangles before dragging, then I don't need to
hold Alt to get the behavior you request. They are still visually
below the pink squiggle, but I can now drag the 'lower' group. Is this
expected behavior?

Nope. It's a bug. Kind of surprising that no one noticed it before. I'll look into it.

>it always assumes that when you click and drag something, you want to select and drag that something.

bbyak, I could agree with you if only one object were selected, but selecting multiple objects requires specific actions: dragging a marquee around multiple objects before dragging them (2 clicks), or shift-clicking on multiple objects before dragging them (3 or more clicks). There's no "magic" required, just a check on whether multiple objects are currently selected and whether the drag originated within the boundaries of that selection.

Tom, thanks for clarifying that issue for me in your email. I can't duplicate the behavior you described under 0.45.1 Mac, but it sounds like you've already got it sorted.

And bbyak, sorry to be so vague there. Normally holding down option and dragging causes the document to scroll with the mouse, similar to the "hand" tool in many packages. My concern is that if we are zoomed in far enough that the current selection fills the screen, option-dragging will move the object, rather than scrolling the document as expected.

On Feb 1, 2008 12:04 PM, Matt Rasmussen <email address hidden> wrote:
> bbyak, I could agree with you if only one object were selected, but
> selecting multiple objects requires specific actions: dragging a marquee
> around multiple objects before dragging them (2 clicks), or shift-
> clicking on multiple objects before dragging them (3 or more clicks).
> There's no "magic" required, just a check on whether multiple objects
> are currently selected and whether the drag originated within the
> boundaries of that selection.

I don't see how the fact of multiple selection affects this. It was
the past selection that was multiple, not the new one. The new one is
still done or not done by a single click.

Making anything depend on whether selection is multiple is not a good
idea IMHO. We have no other UI behavior that depends on it. People
will assume that either for single selections or for multiple
selections (depending on their expectations) it's broken. Explaining
the intricate logic like this is no fun for those who support and
document the program.

Also, Alt+drag has one more benefit: with it you don't even need to
start dragging on the selection. You can start dragging anywhere on
canvas.

As for scrolling, we don't use alt+drag for that but we have plenty of
other ways to scroll.

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

You've gone to heroic lengths, and I appreciate you for taking the time to dig into this with me, Bulia. I'm still not convinced that the alteration in interface behavoir is any less logical than requiring a novel hotkey. Still, I tested the example in Adobe Illustrator, and it agrees with you.

So I'll put this thread to rest with the following suggestions:

1. Make it discoverable.
A mention in the contextual "tooltips" at the bottom of the screen would be useful.

2. Fix it in the Mac version.
Option-dragging with one or more objects selected still scrolls the screen. (I'm running v0.45.1.)

On Feb 2, 2008 12:59 AM, Matt Rasmussen <email address hidden> wrote:
> 1. Make it discoverable.
> A mention in the contextual "tooltips" at the bottom of the screen would be useful.

it's there when you press Alt: "Alt: click to select under; drag to
move selected or select by touch"

> 2. Fix it in the Mac version.
> Option-dragging with one or more objects selected still scrolls the screen. (I'm running v0.45.1.)

http://wiki.inkscape.org/wiki/index.php/FAQ#How_to_make_Alt.2Bclick_and_Alt.2Bdrag_work_on_Mac_OS_X.3F

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

"Emulate 3-button Mouse" being the default setting in X11, the keys it traps appear to be behaving as Inkscape expects. I hate to keep bludgeoning this thread, but that doesn't succeed as "discoverable." No one can troubleshoot a problem they don't know exists.

You should ask on the devel list about that, I don't use OSX and have
no idea what works there

On Feb 3, 2008 1:15 AM, Matt Rasmussen <email address hidden> wrote:
> "Emulate 3-button Mouse" being the default setting in X11, the keys it
> traps appear to be behaving as Inkscape expects. I hate to keep
> bludgeoning this thread, but that doesn't succeed as "discoverable." No
> one can troubleshoot a problem they don't know exists.
>
>
> --
> Marquee select ignored if there is an object in the foreground
> https://bugs.launchpad.net/bugs/187531
> You received this bug notification because you are a member of Inkscape
> Bug Team, which is the bug contact for Inkscape.
>

--
bulia byak
Inkscape. Draw Freely.
http://www.inkscape.org

Hi Matt, I'm not sure I completely understand your comment above but here are my interpretations and answers:

1/ you think the problem is with the behaviour of the Alt key on OS X and that the FAQ does not make it discoverable enough.
Unfortunately, this ball is not ours to play with. Apple has been changing the key map with every other version of X11, which makes it nearly impossible to predict in advance wether alt will actually behave as alt or not (yes this is a pain). We could be shipping our own keymap, also fixing the Ctrl-Command key behavior (i.e. make command work as control so that you can use Inkscape as any OS X app) but since the default option is also to ignore this and follow system keymap, this would probably be a mess. If you are on Leopard, just deselect all options in the Input tab of X11 prefs and put this:
<code>
! This one switches both alt keys to be alt:
keycode 66 = Alt_L
keycode 69 = Alt_R
clear mod1
add mod1 = Alt_L Alt_R
! switch meta and control
clear mod2
clear control
add mod2 = Control_L Control_R
add control = Meta_L Meta_R
</code>
in a file named .Xmodmap in your home directory.This will make Alt behave as intended and use Command instead of control (to copy, paste, ...). It may also work on Tiger and earlier, but as explained, it's difficult to be positive about it.

2/ the Alt key is fine but you think that the tooltip at the bottom of the window does not make Alt's behavior discoverable enough.
The help text in this portion of the UI can be very long for some tools, even in their default state. It's therefore impossible to fit the description of the behavior of all "modes" of the tool (all combinations of modifiers) at once. As a result, to know what the modes are, you have to press the modifiers and read the text that changed accordingly. Granted, this supposes that you know that the modifiers will have some effect and that such modes actually exists but I think:
   . you'll find this in any Inkscape tutorial. The different modes of action of all tools are what makes Inkscape special, powerful and pleasant to use.
   . you'll probably "accidentally" notice that the text changes when you press a modifier trying to copy/paste/whatever, and this should give you a tip about how you're supposed to use this part of the UI: systematically press the modifiers one after the other in each tool to discover their function.

I am a big fan of this kind of UI: it seems simple and plain and you can use it right away (the default behavior of each tool is straightforward), but digging around a bit pays and uncovers powerful functions. This is how OS X functions by the way: there are plenty of hidden gems when you press Command or Option while performing otherwise simple actions (and most of the time you don't even have a visual clue about it beforehand, as you have in Inkscape!).

If that still does not convince you, do you have a suggestion on how to make these behaviors more discoverable?

NB: don't copy the <code> blocks in .Xmodmap, this was a (failed) attempt to format the text in between properly. Copy eveything that's in between <code> and </code>.

Thanks, JiHO. Sorry to take so long responding to your post; I've been sick this week.

Points 1 and 2 -- the "discoverability" and Option (Alt) key behavior -- are actually not seperate issues, in this case. Under X11's default settings Emulate Three Button Mouse steals the Option key for it's 2D scrolling function. That behavior appears to the user, however, to be Inkscape's.

With the Option key being stolen by X11 itself, Inkscape doesn't appear to register when it's pressed, and no tooltip explaining what it's meant to be doing is displayed at the bottom of the window. A user would have to happen upon the Emulate Three Button Mouse issue while searching for something else on the site in order to even realize that anything was wrong. As far as assuming that all users will go through the tutorial... unless it's the first level of a videogame, that's probably not the safest assumption to make.

The simplest solution that I can picture is a dialogue that appears when Inkscape opens: "Emulate Three Button Mouse is currently selected in X11's Preferences. This will prevent some keys that Inkscape uses from functioning correctly. Would you like to turn off Emulate Three Button Mouse while Inkscape is running?" It presents the choice plainly, explains why it's needed, and details what it's offering to do. (A link to a more detailed explanation on the FAQ would be friendly there too.)

As far as the deeper philosophy of modifier keys question goes, overall I'm completely with you, but Blender haunts me. I'll type up some quick thoughts in a straight-to-you email when I get a moment.

I changed the title of the bug report according to your comments. Indeed we may do what you advise. I'm assigning this to Michael who has done the alert pannel for the absence of X11. Michael could we do something along these lines for this issue? Something which checks for
  defaults read org.x.X11 enable_fake_buttons
  defaults read org.x.X11 enable_key_equivalents
and shows the dialog appropriately. The issue then would be to know how to change it (I'm guessing a defaults write would be useless if X11 is already started so it should be killed and only then defaults write the right value --i.e. 0 for both).