<AWT Dev> <Swing Dev>  Review request for 8166772: Touch keyboard is not shown for text components on a screen touch
alexander.zvegintsev at oracle.com
Tue Sep 26 04:11:16 UTC 2017
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):
> 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,
> 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,
>>> On 17/08/2017 13:20, Anton Litvinov wrote:
>>>> 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
>>>> 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
>>>> Thank you,
More information about the awt-dev