<Swing Dev> [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

[Alexander Zvegintsev]

+1

Thanks,
Alexander.

On 22/09/2017 06:09, Anton Litvinov wrote:
> Hello Sergey,
>
> Thank you very much for review of this fix. The second version of the 
> fix with minor changes in 3 places which address your remarks is 
> created. The new fix version applied to the today's version of the 
> consolidated repository "jdk10/client" was verified in my local 
> environment successfully. Could you please look at the new version of 
> the fix.
>
> Webrev (the 2nd version): 
> http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.01
>
> The 2nd version of the fix contains the next changes:
> 1.  "SunToolkit.java" file - Now "true" is used as the default value 
> for the system property "awt.touchKeyboardAutoShowIsEnable".
> 2.  The 1st version of the fix was not thread-safe, only in case, when 
> more than 1 EDT could exist in the process, in 2 places: 
> "WToolkit.java" file (access to the fields "compOnTouchDownEvent", 
> "compOnMousePressedEvent"), "awt_Toolkit.cpp" file (deletion and 
> assignment of "NULL" to the field "m_touchKbrdExeFilePath" in the 
> method "ShowTouchKeyboard()").
>     - "WToolkit.java" - The modifier "volatile" was added to the 
> fields "compOnTouchDownEvent", "compOnMousePressedEvent".
>     - "awt_Toolkit.cpp" - Code deleting and assigning NULL to 
> "m_touchKbrdExeFilePath" in the method "ShowTouchKeyboard()" was 
> substituted for the code which outputs into the trace message in case, 
> if launching the touch keyboard system application fails.
>
> Could you please answer my question.
> - Should CCC request be filed for the new system property 
> "awt.touchKeyboardAutoShowIsEnable", whose value is considered as 
> "true" by default, if it is not specified by the user explicitly while 
> launching a Java application?
>
> Thank you,
> Anton
>
> On 05/09/2017 18:15, Sergey Bylokhov wrote:
>> Hi, Anton.
>> The fix looks good.
>>  - But can you please recheck that is is not necessary to use 
>> additional synchronization in showOrHideTouchKeyboard() if a few EDT 
>> will be used.
>>  - I suggest to invert the awt.touchKeyboardAutoShowIsEnabled and use 
>> true as default value, we will have more coverage and feedback in 
>> this case. This property will be used as a workaround if some bugs 
>> will be found.
>>
>> On 8/30/17 11:51, Anton Litvinov wrote:
>>> Hello dear reviewers,
>>>
>>> Could anybody please look at this review request?
>>>
>>> Thank you,
>>> Anton
>>>
>>> On 17/08/2017 13:20, Anton Litvinov wrote:
>>>> Hello,
>>>>
>>>> Could you please review the following fix for the bug.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166772
>>>> Webrev: http://cr.openjdk.java.net/~alitvinov/8166772/jdk10/webrev.00
>>>>
>>>> The bug is the fact that, when a user touches any Swing or AWT text 
>>>> component, for example "JTextField", "JTextArea", "TextField", 
>>>> "TextArea", by means of a touch screen on a host with MS Windows 
>>>> 10/8.1/8 OS, the system touch keyboard is not shown automatically. 
>>>> Please find a detailed description of the bug, screenshots 
>>>> depicting the touch keyboard and a compilable test case with 
>>>> Swing/AWT text components in JBS bug record. Also a summary of the 
>>>> done research of the issue with a description of identified 
>>>> approaches for its resolution are reported in my last comment in 
>>>> the bug record.
>>>>
>>>> THE FIX:
>>>> On a very abstract level the fix functioning can be presented by 
>>>> the next 3 stages:
>>>>
>>>> Stage 1.
>>>> The fix adds support of "WM_TOUCH" system window messages to AWT 
>>>> native peer windows through C++ class "AwtComponent". It 
>>>> "processes" "WM_TOUCH" message and marks 
>>>> "java.awt.event.MouseEvent", which is created as a result of 
>>>> handling of the further coming "WM_LBUTTONDOWN", "WM_LBUTTONUP" 
>>>> messages sent by the system in substitution for this "WM_TOUCH" 
>>>> message, by the new private field flag 
>>>> "MouseEvent.causedByTouchEvent".
>>>>
>>>> Stage 2.
>>>> Then on Java level the fix handles "MouseEvent", "FocusEvent" 
>>>> received only by the instances of "java.awt.TextComponent", 
>>>> "javax.swing.text.TextComponent" in 
>>>> "WToolkit.showOrHideTouchKeyboard()" called from 
>>>> "Component.dispatchEventImpl()" and shows or hides the touch 
>>>> keyboard on "MouseEvent.MOUSE_RELEASED" and "FocusEvent.FOCUS_LOST" 
>>>> events by calling corresponding native methods of "WToolkit" class.
>>>>
>>>> Stage 3.
>>>> Showing of the touch keyboard is implemented in C++ class 
>>>> "AwtToolkit" and is done by launching the system application 
>>>> "TabTip.exe" which implements the system touch keyboard. This 
>>>> approach is described in the bug record.
>>>>
>>>> FEATURES OF THE FIX:
>>>> 1. By default all native and Java parts of the fix do not function 
>>>> at all - the fix is disabled. To enable the fix the application 
>>>> should be run with "-Dawt.touchKeyboardAutoShowIsEnabled=true" 
>>>> option. Handling of this new property is implemented in 
>>>> "sun.awt.SunToolkit" class.
>>>>
>>>> 2. Native parts of the fix functions only on MS Window 8 or later.
>>>>
>>>> 3. The fix implements automatic showing of the touch keyboard for 
>>>> the following 2 use cases:
>>>>     a.  The user touches the text components using the touch screen.
>>>>     b.  The user does mouse clicks on the text components, while no 
>>>> any keyboard is attached to the host.
>>>>
>>>> FIX LOGICAL STRUCTURE BY SOURCE CODE:
>>>> 1. Core of the fix:
>>>>     Native code:  awt_Toolkit.[h/cpp], awt_Component.[h/cpp], 
>>>> awt_MouseEvent.[h/cpp], awt.h
>>>>     Java:  SunToolkit.java, WToolkit.java, Component.java, 
>>>> MouseEvent.java, AWTAccessor.java
>>>>
>>>> 2. Changes in all remaining Java files are connected with retaining 
>>>> of the flag value "MouseEvent.causedByTouchEvent" during creation 
>>>> of the new instances of "MouseEvent" class based on the original 
>>>> "MouseEvent" instances.
>>>>
>>>> Work of the fix was verified both in the environment with the real 
>>>> touch screen device and in the environment with the emulated touch 
>>>> screen.
>>>>
>>>> Thank you,
>>>> Anton
>>>
>>
>>
>