Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-swt-dev] [StyledText] Filtering out Ctrl/Alt key combinations

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



Back to the top