Re: [10] JDK-8148344: Java robot keypress should be able to use extended key code characters as ? ? ?.
Hi, Shashi.
Did you check what kind of events are generated by the external
input methods? Currently input methods works on all platforms and are
able to generate some type events for the Unicode symbols which are
absent on the keyboard(for example Chinese hieroglyphs) but we already
can handle such events(maybe we generate only TYPE events in this case
and skip keyPress/keyRelease events).
On 25/03/2018 22:53, Shashidhara Veerabhadraiah wrote:
Hi, Please review the updated Webrev containing the requested changes:
http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.05/
I believe this change implements a new feature of Unicode key input and the
corresponding key event generation without affecting the existing ascii key
input and key event generations. Hence the regression should be less with this
change.
Some notes with respect to implementation:
1. On linux platform, native api's present only for the extended ascii
support and hence no idea of Unicode input in this platform.
2. On mac platform, I have used the below native api's to implement the
Unicode input to a component and key event trigger from the component to the
respective key listener.
https://developer.apple.com/documentation/coregraphics/1456120-cgeventkeyboardgetunicodestring
https://developer.apple.com/documentation/coregraphics/1456028-cgeventkeyboardsetunicodestring?language=objc
(Set and get Unicode key is supported via the core graphics
event(CGEvent) which is part of the NSEvent structure which is the base
structure for event implementation on mac)
3. On windows platform, I have used the below native api's to perform this
job:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx
(SendInput api supports the Unicode input via the flag
KEYEVENTF_UNICODE)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646271(v=vs.85).aspx
(Upon VK_PACKET, Get and decode the message via GetMessage() and
TranslateMessage(). This produces a WM_CHAR message containing the respective
Unicode key)
Thanks and regards,
Shashi
-Original Message-
From: Sergey Bylokhov
Sent: Monday, November 27, 2017 11:43 PM
To: Shashidhara Veerabhadraiah ; Semyon
Sadetsky ; awt-dev@openjdk.java.net
Subject: Re: [10] JDK-8148344: Java robot keypress should be able to
use extended key code characters as ? ? ?.
Hi, Shashi.
Also we should check what events are come to the application when
this new API will be used. For example if 'm' will be pressed what
notifications will be posted to the
application?(keyTyped/keyPressed/keyReleased)
The test is still manual, I suggest to change it to automated and validate the behavior
of "keyTyped/keyPressed/keyReleased". I suggest to implement it first and check
that it works as expected on macOS and windows. After that we can take a look to the
linux platform(For example I think KeyEvent.getExtendedKeyCodeForChar() should work on
linux, and we can check can it be used in the proposed fix or not)
On 20/11/2017 21:03, Shashidhara Veerabhadraiah wrote:
Hi Sergey, Please find the code updates that you asked for. As discussed I have
raised an exception for the linux platform as there is no equivalent functions
being implemented yet.
Webrev: http://cr.openjdk.java.net/~sveerabhadra/8148344/webrev.04/
shashi
-Original Message-
From: Shashidhara Veerabhadraiah
Sent: Thursday, November 16, 2017 12:36 PM
To: Sergey Bylokhov ; Semyon Sadetsky
; awt-dev@openjdk.java.net
Subject: Re: [10] JDK-8148344: Java robot keypress should be able to
use extended key code characters as ? ? ?.
Hi Sergey, Below are my replies:
shashi
-Original Message-
From: Sergey Bylokhov
Sent: Tuesday, November 14, 2017 3:32 AM
To: Shashidhara Veerabhadraiah
; Semyon Sadetsky
; awt-dev@openjdk.java.net
Subject: Re: [10] JDK-8148344: Java robot keypress should be able to
use extended key code characters as ? ? ?.
Hi, Shashi.
115 @Override
116 public void keyReleaseUnicode( int key ) {
117 // No special functions that implements a unicode key press
118 // and release in linux platform. Hence falls back to the
119 // default ASCII key press/release functions.
120 keyReleaseImpl(key);
121 }
We should do something in this part of the fix, because we cannot use unicode
point as a keyCode. It will produce incorrect result.
[Shashi] As discussed in the meeting, will add a unsupported exception in the
following Webrev.
Also we should check what events are come to the application when this
new API will be used. For example if 'm' will be pressed what
notifications will be posted to the
application?(keyTyped/keyPressed/keyReleased)
[Shashi] It sends out the keyPressed/keyReleased events(WM_KEYUP/WM_KEYDOWN)
events. The current code takes into account of the Unicode chars and uses the
Unicode functions like ::ToUnicodeEx() to scan th
Re: RFR: JDK-8194327 [macos] AWT windows have incorrect main/key window behaviors
Hi, Alan. I just found a few side effects in the test. - All other tests(actually all java applications) which are executed after the new test will show colorPanel(until it will not be closed manually). - If the Finder will be opened in full screen(or in the location where the test will show the test windows) then the test will fail. Maybe it is better to use some other application to deactivate the test? Can we implement it using other java application?(you can run the same TestMainKeyWindow.main() and pass some flag to it) On 05/04/2018 16:15, Alan Snyder wrote: Thank you for your comments. Here is the updated webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.01/ Alan On Apr 4, 2018, at 9:34 AM, Sergey Bylokhov mailto:sergey.bylok...@oracle.com>> wrote: Hi, Alan. A few comments about the test: - It is a mac specific and JtregNativeJdk should compile it on mac only - It should close all windows at the end, currently it leaves Finder opened. - it tries to use NSWindowStyleMask/NSWindowStyleMaskTitled which are available in >10.12. We only plan to move to 10.9 soon. So the test should skip it or use NSInteger/NSTitledWindowMask for macOS < MAC_OS_X_VERSION_10_12. - It looks like other tests in JtregNativeJdk.gmk use libtest+Some useful name, I suggest to use the same instead of bugid(same for the test name "Test.java"). BUILD_JDK_JTREG_LIBRARIES_LIBS_libtest819432 On 02/04/2018 19:35, Alan Snyder wrote: Please review the following change to the macOS AWT. Bug: https://bugs.openjdk.java.net/browse/JDK-8194327 Webrev: http://cr.openjdk.java.net/~serb/alans/8194327/webrev.00/ The goal of this change is to allow a Java desktop application on macOS to properly coexist with a native utility panel, such as the native color chooser. The native color chooser is an example of a window that can become the key (focused) window but cannot become the main window. If the previously active window is a Java frame, it should resign key window status (lose focus), but retain the main window status. A window that is main but not key does not own the keyboard focus, but it appears active, and if it is using the screen menu bar, it may be invoked to process a menu item action (if the menu item is not already handled by the key window). The current macOS AWT does not support this combination of window states. A Java window is either key and main, or neither. When the color chooser becomes key (obtains focus), the Java frame resigns both key and main status. This change allows the key window status to be resigned while retaining the main window status, with the appropriate behavior. Note that with this change, it remains impossible to implement a Java window that behaves like the native color chooser (i.e., can become key but not main). That would require a much bigger change. Alan -- Best regards, Sergey. -- Best regards, Sergey.
Re: Proposal:AIX's IME support
Hi, Ichiroh. Your contribution is welcome. Can you send the change for review as a webrev on cr.openjdk.java.net? On 09/04/2018 02:09, Ichiroh Takiguchi wrote: Hello, IBM would like to propose another Input Method Framework (IMF) implementation against IBM AIX platform. Same IMF implementation was used by IBM Java8 for AIX. IBM would like to contribute this IMF implementation to OpenJDK project. AIX's Input Method Editor (IME) working behavior is not same as Linux's and Solaris' one. On OpenJDK JDK9 for AIX, users cannot input any East Asian character with their locale by this IME. We think this situation is critical. Put modified files under src/java.desktop/aix/* directories in order not to affect the other unix platform. I'd like contribute following 4 files: M make/lib/Awt2dLibraries.gmk A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c We need to apply too many changes including JNI, so we copied following 3 files from unix directory to aix directory: * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c Then, we modified them. I'd appreciate any feedback please, and how I would go about obtaining a sponsor and contributor? Thanks, Ichiroh Takiguchi IBM Japan, Ltd. -- Best regards, Sergey.
Re: RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols
Hello Severin, I'm ok with this solution for now. Could you please reduce the indentation on line 652. In the build system we like 4 spaces for continuation indent [1] /Erik [1] http://openjdk.java.net/groups/build/doc/code-conventions.html On 2018-04-09 06:39, Severin Gehwolf wrote: Hi, Could somebody please review this build fix for libfontmanager.so. The issue for us is that with some LDFLAGS the build breaks as described in bug JDK-8196218. However, we cannot link to a providing library at build-time since we don't know which one it should be: libawt_headless or libawt_xawt. That has to happen at runtime. The proposed fix filters out relevant linker flags when libfontmanager is being built. More details are in the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ Testing: I've run this through submit[1] and got the following results. SwingSet2 works fine for me on F27. I'm currently running some more tests on RHEL 7. - Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. 0 Failed Tests Mach5 Tasks Results Summary NA: 0 UNABLE_TO_RUN: 0 EXECUTED_WITH_FAILURE: 0 KILLED: 0 PASSED: 82 FAILED: 1 Test 1 Failed tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- debug-31 SetupFailedException in setup...profile run-test-prebuilt' , return value: 10 Not sure what this test failure means. Could somebody at Oracle shed some light on this? Thanks, Severin
RFR: 8196516: libfontmanager must be built with LDFLAGS allowing unresolved symbols
Hi, Could somebody please review this build fix for libfontmanager.so. The issue for us is that with some LDFLAGS the build breaks as described in bug JDK-8196218. However, we cannot link to a providing library at build-time since we don't know which one it should be: libawt_headless or libawt_xawt. That has to happen at runtime. The proposed fix filters out relevant linker flags when libfontmanager is being built. More details are in the bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8196516 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8196516/webrev.01/ Testing: I've run this through submit[1] and got the following results. SwingSet2 works fine for me on F27. I'm currently running some more tests on RHEL 7. - Mach5 mach5-one-sgehwolf-JDK-8196516-20180409-1036-17877: Builds PASSED. Testing FAILURE. 0 Failed Tests Mach5 Tasks Results Summary NA: 0 UNABLE_TO_RUN: 0 EXECUTED_WITH_FAILURE: 0 KILLED: 0 PASSED: 82 FAILED: 1 Test 1 Failed tier1-debug-jdk_open_test_hotspot_jtreg_tier1_compiler_2-windows-x64- debug-31 SetupFailedException in setup...profile run-test-prebuilt' , return value: 10 Not sure what this test failure means. Could somebody at Oracle shed some light on this? Thanks, Severin
Proposal:AIX's IME support
Hello, IBM would like to propose another Input Method Framework (IMF) implementation against IBM AIX platform. Same IMF implementation was used by IBM Java8 for AIX. IBM would like to contribute this IMF implementation to OpenJDK project. AIX's Input Method Editor (IME) working behavior is not same as Linux's and Solaris' one. On OpenJDK JDK9 for AIX, users cannot input any East Asian character with their locale by this IME. We think this situation is critical. Put modified files under src/java.desktop/aix/* directories in order not to affect the other unix platform. I'd like contribute following 4 files: M make/lib/Awt2dLibraries.gmk A src/java.desktop/aix/classes/sun/awt/X11InputMethod.java A src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c A src/java.desktop/aix/native/libawt_xawt/xawt/XlibWrapper.c We need to apply too many changes including JNI, so we copied following 3 files from unix directory to aix directory: * src/java.desktop/unix/classes/sun/awt/X11InputMethod.java * src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c * src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c Then, we modified them. I'd appreciate any feedback please, and how I would go about obtaining a sponsor and contributor? Thanks, Ichiroh Takiguchi IBM Japan, Ltd.
