[Laszlo-dev] For Review: Change 20090602-bargull-GPN Summary: DHTML: add "updateControlKeys" to LzKeyboardKernel

[Max Carlson]

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 bargull at 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