Bug 24393 - DCR - Need to support Mac command key in SWT
Summary: DCR - Need to support Mac command key in SWT
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: SWT (show other bugs)
Version: 2.0   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P2 normal (vote)
Target Milestone: ---   Edit
Assignee: Steve Northover CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-10-04 10:55 EDT by Steve Northover CLA
Modified: 2003-03-03 21:02 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Northover CLA 2002-10-04 10:55:32 EDT
 
Comment 1 Steve Northover CLA 2002-10-04 11:10:02 EDT
Here is the plan.  We need to add a new SWT constant, SWT.COMMAND and possibly 
new API to Display to control how this SWT.COMMAND is mapped on platforms that 
do and do not have this key (read on).  The API in Display is still under 
consideration.

1) On non-Mac platforms (that typically only have 3 modifier keys SWT.ALT, 
SWT.CONTROL, SWT.SHIFT), for now we map this key to SWT.CONTROL.  Note that 
SWT.COMMAND must have a different value from SWT.CONTROL (can't be assigned 
dynamically) because an app could get this value and write it out on one 
platform and read it back on another.

2) On the Mac, SWT.COMMAND maps to the Apple command key.  All code that 
attempts to map SWT.CONTROL to SWT.COMMAND needs to be deleted or rewritten.  
When a Mac user presses Control, he will get control.  When he presses Command, 
he will get command.

NOTE: This means that for a short time, until the mapping API in Display is 
defined, Eclipse will look stupid on the Mac (it will no longer use the Command 
key for Cut/Copy/Paste) and will not look like a good Mac app.  That's OK for 
now because we are not updating the drop on the web page.

Comments?
Comment 2 Steve Northover CLA 2002-10-04 11:23:37 EDT
I have already added SWT.COMMAND so that we can experiment but not released any 
code that uses it.
Comment 3 Andre Weinand CLA 2002-10-04 11:39:41 EDT
Yes, let's do this!
The only place where the mapping between Control and Command occurs is in 
MenuItem.setAccelerator(int menu, short index, int accelerator) and in
MacEvent.getStateMask().
Comment 4 Steve Northover CLA 2002-10-04 13:06:33 EDT
I have the code ready for Windows and Motif.  I'm about to do GTK.  Then I will 
release them.  At that time SSQ should do Photon.
Comment 5 Steve Northover CLA 2002-10-04 14:50:13 EDT
Code released on Windows and Motif.
Comment 6 Steve Northover CLA 2002-10-07 15:42:46 EDT
Code released on GTK.
Comment 7 Steve Northover CLA 2002-10-10 08:41:31 EDT
Ok, the changes to automatically map SWT.COMMAND to SWT.CONTROL break 
StyledText.  These changes need to come out or be disabled by the yet to be 
determined "API in display" before Tuesday.  SSQ to to nothing on Photon.  SN 
to temporarily disable the free mapping on the other platforms.
Comment 8 Steve Northover CLA 2002-10-10 17:08:22 EDT
The changes have been removed from Windows, GTK and Motif.  The constant 
remains.  Obviously, the automatic mapping strategy will not work.  I believe 
the only strategy that will work would be one where SWT.COMMAND has the same 
value as SWT.CONTROL when the mapping flag is set.

From now on, I will experiment with Windows and the Mac.
Comment 9 Steve Northover CLA 2002-10-17 14:49:28 EDT
Ok, the new idea is to add 4 new masks, SWT.MOD1, SWT.MOD2, SWT.MOD3 and 
SWT.MOD4 in addition to the new SWT.COMMAND.  Programs that want to use the 
primary modifier for the platform use SWT.MOD1 (it's CONTROL on Windows and 
COMMAND on the Mac).  Programs that need to ensure that a certain modifier is 
pressed look for the modifier (ie. SWT.CONTROL is the control key on all 
platforms).

The emulated table and tree use MOD1 and MOD2 so they work properly on the Mac 
and Motif.  I have not touched StyledText because I'm not sure what the right 
thing is.  Andre, you have a better perspective on this.

So, there is still no automatic mapping strategy either global or local because 
I'm not sure how one would work.  I believe the new constants are orthagonal.

I have released code on the Mac that get's rid of the "free mapping CONTROL to 
COMMAND" and fixed the keyboard to be the same as the other platforms.  The 
Eclipse menus look funny as expected and the hot keys are Ctr+S instead of 
Command+S.

This PR is still not closed.
Comment 10 Steve Northover CLA 2003-01-23 13:08:08 EST
Ok, new masks have been added to represent all future key modifiers, keys and 
mouse masks.  They should be used instead of expressions like "SWT.ALT | 
SWT.SHIFT | SWT.CTRL | SWT.COMMAND" (use SWT.MODIFIER_MASK instead).  In 
addition, they can be used to extract portions of an accelerator. (An 
accelerators is an int made up by ORing modifiers and keys.  Once the ORing has 
happened and you have only the int, there used to be no way to get the parts 
back out again).

Here are the new masks are:

SWT.KEY_MASK
SWT.KEYCODE_BIT
SWT.MOUSE_MASK
SWT.MODIFIER_MASK

SWT.KEYCODE_BIT has been added so an application can distinguish a keyCode from 
a character.

Lynne, can you fix StyledText to use the new masks?  I am going to fix the 
emulated tree and table.  Let me know if there is a problem.  Once this is 
done, I'm going to close this PR.
Comment 11 Lynne Kues CLA 2003-01-24 12:21:01 EST
changed StyledText.
Comment 12 Steve Northover CLA 2003-03-03 21:02:24 EST
This has been fixed for a while.