Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 346597

Summary: Support RWT.ACTIVE_KEYS to optimize KeyListener on Widget
Product: [RT] RAP Reporter: Sebastien Arod <sebastien.arod>
Component: RWTAssignee: Project Inbox <rap-inbox>
Status: CLOSED FIXED QA Contact:
Severity: enhancement    
Priority: P2 CC: stephan.leichtvogt, tbuschto
Version: 1.4   
Target Milestone: 1.5 M5   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 348559    
Attachments:
Description Flags
Bundle to reproduce active keys bug none

Description Sebastien Arod CLA 2011-05-20 04:04:30 EDT 
Defining a KeyListener on a widget causes every key event to make a server call.

For a text widget this can makes the text entry not very responsive.

Allowing to define RWT.ACTIVE_KEYS on the widget data to limit the active keys similarly to what have been done on Display filters would allow to limit the number of server calls and improve the performance.
Comment 1 Ralf Sternberg CLA 2011-06-01 06:35:05 EDT 
That's an interesting suggestion.

One issue I see is that the same constant RWT.ACTIVE_KEYS would have slightly different effects for Display and Widget. While Display#setFilter() does not fire any key events by default, a key listener on a widget fires every key event. So on Display this setting would *enable* key events, on Widget it would effectively *disable* all key events that are not in the list.

However, I tend to think that the benefit of being able to limit the key event requests sent by the client outweighs this inconsistency. I would also tend to re-use the constant instead of introducing a new one for the sake of clarity. Moreover, the type and semantics of the values are the same in both cases, so it makes sense to me to re-use the existing constant.
Comment 2 Stephan Leicht Vogt CLA 2011-11-16 10:31:49 EST 
As this bug is quiet since 5 months and we do depend on the proposed functionality I will try to write a patch for it. 
Would this be ok? Or did someone already invest some time in this?
Comment 3 Tim Buschtoens CLA 2012-01-03 11:12:17 EST 
Fixed in CVS HEAD.
Comment 4 Stephan Leicht Vogt CLA 2012-01-04 08:42:34 EST 
Created attachment 209002 [details]
Bundle to reproduce active keys bug

Thanks a lot for implementing this enhancement. Unfortunately it does not work all correct for me. I write a snippet which should show my problem.
Comment 5 Stephan Leicht Vogt CLA 2012-01-04 08:44:02 EST 
As stated in the comment to attachment 209002 [details] it does not work for me.
Comment 6 Tim Buschtoens CLA 2012-01-04 12:37:00 EST 
Okay, i found two issues i opend separate bugs for:

* Bug 367875 - ActiveKeys with CTRL+[char] don't work on Text widget 
* Bug 367876 - ActiveKeys with CTRL+[char] dont always work in IE, Webkit

The snippet you provided wont't work in any case because the active keys are only evaluated if the widget has a key listener attached and the widget is focused. (Its also described that way in the javadoc for ACTIVE_KEYS). If for some reason you want to use display event filter instead, you can attach an empty key listener to the widget (or use ACTIVE_KEYS on filter). If there is another issue, please open a new bug.