P T Withington wrote:
This looks good to me.
I'm hoping Max can answer the question about canceling events and LPP-8200.
This should be resolved when André gets the complete fix in - he's
breaking my (large) fix across a series of changes to improve testability.
I believe meta should be treated like any other "shift key". It is
annoying that in swf runtimes it is mapped to control. Presumably this
is because sometime back in the mid-80's Apple computers did not have a
control key. Maybe Adobe ought to be told that it is not 1980 any
more. In the mean time, I would treat the (broken) keymapping in the
swf runtime as a quirk of swf, not as something that should be
duplicated in the DHTML runtime.
This would be nice, but LZX developers are most used to the behavior in
SWF - and expect DHTML to act exactly the same. So, we're in the
position of emulating swf(8!) behavior for now!
Presumably people writing DHTML apps will benefit if they can
distinguish more shift keys.
---
Something that is really a mystery to me is the internal protocol
between the keyboard kernel and LzKeys. The kernel sends both a map of
the abstract keys that have changed state, _and_ the last physical key
code. LzKeys maps the abstract keys to Flash physical keycodes, but if
it finds any abstract key that does not have a flash mapping, it uses
the platform physical code (which may or may not intersect with a Flash
physical code). I'm guessing this was an attempt to make LZX code more
portable, but it's a pretty messy transformation (and looks to me like
it could cause some bugs because of the way the exception code works).
In the long run, it would seem like a better approach would be to create
a new set of LzKeys interfaces that dealt in abstract keys (as in
Unicode characters + strings to represent keys that do not correspond to
characters, like F1, Page-up, etc.) plus shift key states, which would
be uniform across platforms; and eventually deprecate the interfaces
that deal with Flash keycodes.
On 2009-06-02, at 10:27EDT, André Bargull wrote:
These are just the changes for LzKeyboardKernel. We still need to
decide whether "updateControlKeys()" needs to handle the 'metaKey' for
LPP-8210.
Change 20090602-bargull-GPN by barg...@dell--p4--2-53 on 2009-06-02
15:54:52
in /home/Admin/src/svn/openlaszlo/trunk
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: DHTML: add "updateControlKeys" to LzKeyboardKernel
New Features:
Bugs Fixed: LPP-8218 - DHTML: issues with contextmenu onmenuopen,
dragging (partial)
Technical Reviewer: max, ptw
QA Reviewer: hqm
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
Call "updateControlKeys()" instead of "__keyboardEvent()" for
mouse-events.
Set "cancelBubble" and "returnValue" after invoking
"updateControlKeys()" to mimic old behaviour (this is actually wrong,
see LPP-8200, but reduces testing effort right now). "keyCode" is set
to 0 for mouse-events in IE, Opera, Safari, so you only need to test
for keyCode==0 (Firefox is irrelevant in this case, because it sets
keyCode to `undefined` for mouse-events).
Tests:
test/lfc/legals/keyboardandmouse.lzx?lzr=dhtml still works as expected
Files:
M WEB-INF/lps/lfc/kernel/dhtml/LzKeyboardKernel.js
M WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js
M WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js
Changeset:
http://svn.openlaszlo.org/openlaszlo/patches/20090602-bargull-GPN.tar
--
Regards,
Max Carlson
OpenLaszlo.org
