+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
