MouseEvent, control key, and Macintosh

Thread view:

Peter Duniho - 15 Jan 2008 08:20 GMT

I naïvely thought that I would be able to use Java as a cross-platform
development environment. But it seems that even there, operating systems
can interfere?

I am specifically running into a problem where on the Macintosh, holding
the Control key down suppresses the mouseDragged event. I receive a
mousePressed, but then even when the mouse button is held down while the
mouse is moved, I only get a mouseMoved event, rather than a mouseDragged
event.

I _think_ this is because the Mac uses a mouse click with the Control key
down as a signal for some applications to display a context menu. But I'm
not sure if this is happening at the OS level, or if this is something
that Apple's Java runtime implementation is doing. If the latter, I'm
curious as to whether there's a Java program setting somewhere I can use
that will disable it and allow for generic handling of a mouse click
+ control key event.

I realize the number of people actually testing on the Mac is probably
relatively small. I also realize that because Apple's implemented their
own Java runtime, Java on the Mac has a sort of second-class, poor
stepchild status. But I remain hopeful that someone in this newsgroup may
have some insight to share anyway. :)

There are obvious workarounds and I can deal with that if I have to. But
I'd like to better understand the details of this issue, if they are to be
had.

Thanks,
Pete

Reply to this Message

Gordon Beaton - 15 Jan 2008 08:15 GMT

> I am specifically running into a problem where on the Macintosh,
> holding the Control key down suppresses the mouseDragged event. I
> receive a mousePressed, but then even when the mouse button is held
> down while the mouse is moved, I only get a mouseMoved event, rather
> than a mouseDragged event.

Have you considered that a user holding the ctrl key while dragging
with the mouse might be doing so because he expects a different
behaviour than just dragging alone?

Or that applications on that platform tend to behave uniformly? Why
would you want to break that?

/gordon

--

Reply to this Message

Peter Duniho - 15 Jan 2008 17:40 GMT

> Have you considered that a user holding the ctrl key while dragging
> with the mouse might be doing so because he expects a different
> behaviour than just dragging alone?

Yes, of course I have. And the point is that the user _should_ expect
different behavior. The act of dragging with control key down produces a
different result than without. But if I don't get drag feedback from Java
at all when the control key is down, it's harder to do this.

> Or that applications on that platform tend to behave uniformly? Why
> would you want to break that?

What "uniformly"? My application has no menus at all. No user would ever
expect a context menu to appear in my application when using the control
key with the mouse. In what way is my application supposed to "behave
uniformly" with others?

The entire application is about dragging geometric shapes around.
Allowing the user to affect how that dragging works in a convenient manner
is FAR more important than worrying about whether a user might expect a
menu to pop up in an application that has no menus.

So, I take it that you don't actually have an answer?

Pete

Reply to this Message

Larry A Barowski - 15 Jan 2008 15:20 GMT

>I naïvely thought that I would be able to use Java as a cross-platform
>development environment. But it seems that even there, operating systems
>can interfere?
>
> I am specifically running into a problem where on the Macintosh, holding
> the Control key down suppresses the mouseDragged event.

You shouldn't directly reference the Ctrl key for most anything.
Use Toolkit.getDefaultToolkit().getMenuShortcutKeyMask() .
This is the "Apple" key on a Mac. and the Ctrl key on pretty
much anything else. Mac. users will not expect the Ctrl key to
act as a menu shortcut control key, or, I suppose, to act as a
flag while dragging as you are using it.

Reply to this Message

Peter Duniho - 15 Jan 2008 17:48 GMT

> You shouldn't directly reference the Ctrl key for most anything.

Um...I should, and do, when it's specifically the control key I care about.

> Use Toolkit.getDefaultToolkit().getMenuShortcutKeyMask() .

That's fine if I want to react with a menu. But I don't.

> This is the "Apple" key on a Mac.

On my Mac, the menu shortcut key is the control key. Are you telling me
that not only is Java blocking mouse dragging feedback when the control
key is down, it incorrectly uses the Apple (Command) key as the menu
shortcut key as well?

> and the Ctrl key on pretty much anything else.

If you say so.

> Mac. users will not expect the Ctrl key to
> act as a menu shortcut control key,

I don't want them to, though I have to tell you that speaking as a Mac
user whose Mac pops up a context menu when you click with the control key
held down, I think you're wrong about at least some Mac users. In
applications that do have menus, I do expect the control key to act as a
menu shortcut key.

> or, I suppose, to act as a
> flag while dragging as you are using it.

Why not? The control key is a common enough modifier for dragging in
other contexts. Even if it weren't, I have a very simple program that
pretty much only uses dragging gestures from the mouse for input. There
are no menus at all (see my previous reply), so it would be hard to
understand why a user of the program might incorrectly expect a context
menu to show up when they use the control key while clicking the mouse.

I take it that you too do not have an actual answer?

Pete

Reply to this Message

Larry A Barowski - 15 Jan 2008 23:02 GMT

>> You shouldn't directly reference the Ctrl key for most anything.
>
> Um...I should, and do, when it's specifically the control key I care
> about.

If you use "Shift", "Alt", and the menu shortcut key, you will get
three useable modifier keys on Windows, Mac, and most UNIX/
Linux systems.

>> Use Toolkit.getDefaultToolkit().getMenuShortcutKeyMask() .
>
[quoted text clipped - 6 lines]
> key is down, it incorrectly uses the Apple (Command) key as the menu
> shortcut key as well?

getMenuShortcutKeyMask() will return the mask for whichever key
you have mapped to the "Command" action. By default, that is the
"Command" key.

>> Mac. users will not expect the Ctrl key to
>> act as a menu shortcut control key,
[quoted text clipped - 4 lines]
> applications that do have menus, I do expect the control key to act as a
> menu shortcut key.

I'm not sure what you're saying here. All of the applications
that I use on a Mac use the key mapped to the Command
action, and only that key, as a menu shortcut key. The only
exceptions I've seen are poorly written Java apps.

>> or, I suppose, to act as a
>> flag while dragging as you are using it.
[quoted text clipped - 7 lines]
>
> I take it that you too do not have an actual answer?

No, I don't know if there is a way to disable the Control key
behavior on Apple's Java implementation. If you find the option
of using a different key unacceptable for some reason, then I
can't help you.

Reply to this Message

Peter Duniho - 15 Jan 2008 23:17 GMT

> If you use "Shift", "Alt", and the menu shortcut key, you will get
> three useable modifier keys on Windows, Mac, and most UNIX/
> Linux systems.

The same thing is true for "Shift", "Alt", and "Control".

> getMenuShortcutKeyMask() will return the mask for whichever key
> you have mapped to the "Command" action. By default, that is the
> "Command" key.

But I don't specifically want the "Command" key, or the "MenuShortcut" key.

> I'm not sure what you're saying here. All of the applications
> that I use on a Mac use the key mapped to the Command
> action, and only that key, as a menu shortcut key. The only
> exceptions I've seen are poorly written Java apps.

I can't tell you whether it's the applications or the OS that decides what
key is used as a menu shortcut key. I suspect it's the OS, not the
application. In any case, on my Mac, in every single application, the
control key is the context menu shortcut key, not the command key.

Maybe Apple changes it according to OS version. Or according to the
computer model. Or according to their whim. All the more reason to pick
a specific modifier key in my case, rather than using a key that varies
according to some unknown rule. After all, it's not like I'm displaying a
menu in this case anyway, so it doesn't make sense to tie the modifier key
to that used for display of menus.

Pete

Reply to this Message

John Maline - 16 Jan 2008 14:22 GMT

> Maybe Apple changes it according to OS version. Or according to the
> computer model. Or according to their whim. All the more reason to
> pick a specific modifier key in my case, rather than using a key that
> varies according to some unknown rule. After all, it's not like I'm
> displaying a menu in this case anyway, so it doesn't make sense to tie
> the modifier key to that used for display of menus.

I think there's a subtle terminology problem going on here.

On the Mac (at least since OS X, I think earlier too)

- Control-click is equivalent to right-click that the 2-button
mouse world has. It's their convention for emulating right-
click in the Mac 1-button mouse world.

Hook a 2-button mouse up to a Mac and you'll see that
right-click does the same thing as control-left-click:
bring up context menus in many places.

- The command key is the primary modifier for menu shortcuts.
It's equivalent to control key for menu shortcuts in the
Windows/Unix world. Note how on the Mac you do Command-C
for copy, compared to Control-C in Windows/Unix?

This is what Java means for
Toolkit.getDefaultToolkit().getMenuShortcutKeyMask()

So if you want a drag modifier and use getMenuShortcutKeyMask(), it'll
do "the right thing" on all platforms. On Mac, that's defined as using
command as the modifier, other platforms use control.

If you insist on hard-coding control, I think the mac will interpret
that as a right-button drag. I don't know enough about Java drag/drop
to know if that's a meaningful thing to talk about or not.

Reply to this Message

Larry A Barowski - 16 Jan 2008 15:28 GMT

> I can't tell you whether it's the applications or the OS that decides what
> key is used as a menu shortcut key. I suspect it's the OS, not the
> application. In any case, on my Mac, in every single application, the
> control key is the context menu shortcut key, not the command key.

That would be the "popup trigger" in Java terminology.

Anyway, here is the same suggestion I gave you, straight from
the horse's mouth, along with an explanation of the problem:
http://developer.apple.com/qa/qa2004/qa1362.html
"If your application supports multiple drag operations, we suggest
first exhausting the other event masks (Alt/Option, Shift,
Meta/Command) as well as combinations of those masks on
Mac OS X."

> Maybe Apple changes it according to OS version.

Terminology confusion aside, you can remap the modifier keys,
which might be handy if you're mainly a non-Mac user.

Reply to this Message

Peter Duniho - 16 Jan 2008 17:52 GMT

> [...]
> Anyway, here is the same suggestion I gave you, straight from
[quoted text clipped - 4 lines]
> Meta/Command) as well as combinations of those masks on
> Mac OS X."

Thank you. The suggestion to use other modifier keys is obvious and I
alluded to it in my original post. But the explicit discussion of the
behavior and its origin is exactly what I was looking for. I very much
appreciate you finding the article and posting the link.

And thank you John for stepping in with your observation of the
communication gap that seems to have been going on.

Pete

Reply to this Message

MouseEvent, control key, and Macintosh

Free Magazines