On Macintosh option+<character> combinations
(with or without shift but without command) get translated into special
characters.
It seems best to allow widgets to get first crack
at characters with modifiers before they get turned into accelerators. At least
that way these OS-dependent choices can remain in the widget.
Bob
----- Original Message -----
Sent: Thursday, July 11, 2002 10:42
AM
Subject: Re: [platform-swt-dev]
[StyledText] Filtering out Ctrl/Alt key combinations
Steve is currently looking at
the problem of how to allow widgets to get "first crack" at handling keyboard
events which come in (eg. before they get turned into accelerators). To do
this, it's going to take a much better understanding of how keyboard events
are dealt with by each of the OS's. I'd say this problem is related. My
feeling is that, we should be doing the same thing on all platforms: either
fire the key event with "LF" or "J" in it, but not one way on some platforms
and the other way on others.
McQ.
| "Knut Radloff"
<knut_radloff@xxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx
07/10/2002 01:33 PM Please respond to platform-swt-dev
| To:
platform-swt-dev@xxxxxxxxxxx cc:
Subject: [platform-swt-dev]
[StyledText] Filtering out Ctrl/Alt key
combinations |
There's a bug (http://dev.eclipse.org/bugs/show_bug.cgi?id=21268) that
requests that the StyledText widget filter out all Ctrl and Alt key
combinations.
On Windows, Ctrl+<character> combinations get
translated into special characters (which are shown in some ASCII tables).
Ctrl+J for example is LF, Ctrl+M is CR. These are inserted in the plain
text widget and in the Windows rich text widget and are not filtered out
(although Wordpad does filter them out). StyledText always inserts CR, LF
and TAB regardless of the Ctrl/Alt state mask in the key event.
The
problem is Linux/Motif. Our key listener doesn't get translated characters
in the key event but just the plain character with the Ctrl statemask.
Consequently StyledText inserts J in the text if you press Ctrl+J. The
plain SWT Text widget does get translated characters, just like on
Windows, and inserts them in the text.
We previously fixed a bug
(http://dev.eclipse.org/bugs/show_bug.cgi?id=12952) and filter out Alt
character combinations so that unused menu mnemonics don't get inserted
into the text. In light of that it seems reasonable to ask that StyledText
filter out Ctrl character combinations as well, if it weren't for the fact
that Windows and possibly other platforms translates them into special
characters.
It would be easy for an application (e.g., Eclipse text
editors) to filter out any Ctrl or Alt decorated characters if we don't
fix this but you couldn't get the old behavior back if StyledText filters
out Ctrl key combinations.
What does the community think about
this? Should StyledText filter out all non-plain characters (i.e., all
characters that have a Ctrl or Alt state mask) or should this be left to
the application? Do any other platforms (Gtk, Mac,...) translate Ctrl key
combinations like Windows does? (I'll check Gtk myself, an excuse to try
out the Gtk
version).
Knut _______________________________________________ platform-swt-dev
mailing
list platform-swt-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
|