|
|
|
| Re: KeyboardTest & non EN keyboards [message #526458 is a reply to message #526431] |
Sun, 11 April 2010 12:38   |
 Ralf Ebert
Messages: 168
Registered: July 2009 |
Senior Member |
|
|
Hi Ketan,
> Your mileage may vary.
for Cocoa this is strong understatement. I created a MAC_DE layout, but the key events on
Cocoa seem to differ, only some characters work, the events look different etc.
From what I've seen this will require some work. I guess I'll finish the @UIThread thing
for Win/Linux/Carbon first, then address German keyboards on these platforms and than make
the tests run on Cocoa. This is more work than I expected to get SWTBot properly working
for me, I have to spread this on the next weeks somehow.
What I don't understand, why do we test AWT and SWT strategies on all platforms? On which
platforms are both AWT and SWT tests running and working? Shouldn't we try to guess the
best strategy for the running platform and test that this best strategy works? From what I
have seen, under no circumstances both strategies will work on Cocoa.
> http://wiki.eclipse.org/SWTBot/Keyboard_Layouts
thanks for the link, I updated the wiki page from what I've learned along the way and
added all the crumbs of information that I had to gather together by asking, reading
newsposts, bug reports and the code. Would be great if you could proof-read it as I pretty
much turned it upside down.
Greetings,
Ralf
--
http://www.ralfebert.de/blog/
http://twitter.com/ralfebert/
|
|
|
| Re: KeyboardTest & non EN keyboards [message #526484 is a reply to message #526458] |
Sun, 11 April 2010 18:00 |
Ketan Padegaonkar
Messages: 873
Registered: July 2009 |
Senior Member |
|
|
On 4/11/10 5:38 AM, Ralf Ebert wrote:
> Hi Ketan,
>
>> Your mileage may vary.
Here's what I know in general, and I may be wrong on some or all of
these statements. Please correct me if I'm wrong.
Keyboard handling done by win32[0] gtk[1] cocoa[2] is done at a very raw
level.
The native keyevents in these windowing systems provide this raw
information to programs using it. This means that when a user presses
'Z', the program gets SHIFT+keyCode and when the user presses 'a', the
program gets keyCode. Converting from these weird keyCodes to a useful
character (printable or non-printable) is done by another translation
layer that handles keyboard layouts.
Things get uglier on keyboards with umlauts on german and french
keyboards and the dreaded ALT_GR key[3] for which SWT has no support for
and the only way out is to fall back to AWT.
SWT(and AWT) does a good attempt at ensuring that these complex
keystrokes work, but they have their own corner cases[4] where they
don't really do what they say they do.
In short, yes this is a messy area for SWTBot to solve, not many people
have solved this problem, and given that each of these systems have
their own weird bugs, it's very difficult to predict which keyboard will
work for a particular user's environment.
The solution for me is to let users choose and even switch keyboard
strategies based on what they are doing. Some of the tests we do at
ThoughtWorks do exactly that – switch the keyboard strategy based on
what os/ws/jdk version it is running on for very specific tests, and set
it back to defaults.
I've spent enough months pondering at swt and awt source code that I'm
convinced there is no other way. I'm however open to ideas on how this
situation could be improved.
– Ketan
[0] - http://msdn.microsoft.com/en-us/library/ms644967(v=VS.85).aspx
[1] -
http://library.gnome.org/devel/gdk/unstable/gdk-Event-Struct ures.html#GdkEventKey
[2] -
http://developer.apple.com/mac/library/documentation/Cocoa/C onceptual/EventOverview/HandlingKeyEvents/HandlingKeyEvents. html#//apple_ref/doc/uid/10000060i-CH7-SW1
[3] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=280824
[4] - https://bugs.eclipse.org/bugs/show_bug.cgi?id=278207
|
|
|
|
Powered by
FUDForum. Page generated in 0.07359 seconds
Search
Help
Register
Login
Home
