date:20170925

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

2017-09-25 Thread 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.

Re: [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

2017-09-25 Thread Anton Litvinov


Hi Shashi,

I am also reviewing your fix since last week. I built "jdk10/client" 
with your fix and was able to see, how the 1st and the 2nd versions of 
your fix work. I have the following remarks and questions to you:


1. The fix causes a rather significant regression, which is a loss of 
the drag functionality using the touch screen. To reproduce it you can 
use "SwingSet2" demo application, where try to move any of the internal 
frames on the first tab of the demo application using the touch screen. 
Also you can try to select text in JTextField in that demo application 
using the touch screen. I think that this regression is serious and 
should be addressed in this fix.


2. Why is it necessary for your fix to handle "WM_POINTERENTER", 
"WM_POINTERLEAVE" messages?


3. According to MSDN the used by you Win32 API function "GetPointerInfo" 
and "WM_POINTER*" messages are available on Windows 8 or later OS 
versions, what means that they are not available on older OS versions, 
for example on Windows 7, and what means that your fix will not resolve 
the bug for Windows 7.


Windows 7 is supported by JDK 9 
(http://www.oracle.com/technetwork/java/javase/jdk9certconfig-3761018.html), 
and obviously JDK 10 also supports Windows 7, therefore the bug should 
be fixed also for Windows 7, if it is reproducible on that OS.


Thank you,
Anton

On 25/09/2017 07:29, Shashidhara Veerabhadraiah wrote:


Hi Alexey, Thank you for pointing that out. I misread the info that 
EnableMouseInPointer() is a must call and would enable the WM_POINTER 
messages being sent to the component. But actually it is not required 
to be enabled and as you rightly pointed out that it would convert the 
WM_MOUSE to the WM_POINTER messages.


Below is the Webrev that does this change. Now since mouse in pointer 
is disabled, the mouse behavior should /_not_/ have any effect at all 
by this software updates.


Webrev: http://cr.openjdk.java.net/~sveerabhadra/8178361/webrev.01/ 



For additional replies, please see below.

Thanks and regards,

Shashi

*From:*Alexey Ivanov
*Sent:* Friday, September 22, 2017 5:19 PM
*To:* Shashidhara Veerabhadraiah 
; Sergey Bylokhov 


*Cc:* awt-dev@openjdk.java.net
*Subject:* Re:  [10] JDK-8178361: JFileChooser does not allow 
to open folders with a double tap when using the touch screen interface


Hi Shashi,

You use EnableMouseInPointer which converts classical WM_MOUSE events 
to WM_POINTER events. This could have substantial effect on AWT 
components behaviour. I am worried about High DPI support, 
drag-and-drop functionality etc.


*/[Shashi] This is not required and hence removed./*

Is there a simpler way to handle double-tap?
Windows converts taps to clicks, i.e. the app receives WM_LBUTTONDOWN 
and WM_LBUTTONUP.
Have you tried to find out why double-tap is not converted to 
double-click?


*/[Shashi] Since the mouse in pointer is disabled and a windows icon 
behavior is different from a windows button behavior(Because the a 
touch on the icon does not translate to a left button down event 
whereas it does for a windows button(file name!!)), it is required to 
bring in the WM_POINTER message type into the component message 
handling routine./*


Do right and middle mouse buttons continue to work as expected? Mouse 
wheel? Any additional mouse buttons?


*/[Shashi] It should not have any effect after mouse in pointer is 
disabled./*


The documentation for EnableMouseInPointer [1] says: “This function 
can be called only once in the context of a process lifetime.” You 
call it for every component created. It would have been enough to call 
it once during Toolkit initialization.



Regards,
Alexey

[1] 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh447467(v=vs.85).aspx 



On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:

Hi Sergey, When I checked it was not working on the Java applications. None 
of the controls could take touch click events but it used to highlight because 
when we touch on the touch screen interface the system moves the cursor over to 
the touch point thereby enabling mouse focus events being sent.

Thanks and regards,

Shashi

-Original Message-

From: Sergey Bylokhov

Sent: Tuesday, September 19, 2017 3:39 AM

To:shashidhara.veerabhadra...@oracle.com
  >> Shashidhara 
Veerabhadraiah


Cc:awt-dev@openjdk.java.net 

Subject: Re:  [10] JDK-8178361: JFileChooser does not allow to 
open folders with a double tap when using the touch screen interface

Hi, Shashi.

Why the bug is JFileChooser specific?

Does it means that it works

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

2017-09-25 Thread Sergey Bylokhov


On 9/25/17 11:49, Anton Litvinov wrote:

Hello Sergey,

Thank you for approval of the fix. Yes, sure, I will file a CSR. Do you 
suggest to file a CSR about the new property 
"awt.touchKeyboardAutoShowIsEnabled" or the whole functionality 
implemented in this fix, particularly - support of automatic showing of 
the touch keyboard without mentioning of this new system property?


It would be good to describe the whole feature.



Thank you,
Anton

On 25/09/2017 17:30, Sergey Bylokhov wrote:

Looks fine.

On 9/21/17 17:39, Anton Litvinov wrote:

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?


I suggest to create a CSR, because this fix introduce some behavior 
change(it does not mean that we will make this property public).








--
Best regards, Sergey.

Re: [10] Review request for 8155197: Focus transition issue

2017-09-25 Thread Semyon Sadetsky


Hi Dmitry,


On 09/25/2017 01:09 PM, Dmitry Markov wrote:

Hi Semyon,

This issue and the problem addressed by 8139218 and 8159432 are slightly 
different. This one is still reproducible on latest 9 and 10 builds using the 
test case attached to the bug or regression test provided with the fix.
I couldn't get the test failed on 9 and 10. But I only tried it on 
Ubuntu. Is the issue a platform dependent?


The problem takes place when we restore focus to a component and its parent 
window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore 
focus synchronously). If the parent window loses the focus during this 
invocation, focus request will fail and focus target will be shifted to next in 
focus traversal cycle. This case is not covered by the changes introduced by 
8139218 and 8159432.
I see. What may prevent to set the input focus synchronously? Since the 
native window already has the focus this should be very deterministic.


--Semyon


Thanks,
Dmitry

On 25 Sep 2017, at 15:58, Semyon Sadetsky  wrote:

Hi Dmitry,

This issue was already fixed in 9. See 8139218 & 8159432.

--Semyon


On 09/23/2017 08:25 AM, Dmitry Markov wrote:

Hello,

Could you review a fix for jdk10, please?

   bug: https://bugs.openjdk.java.net/browse/JDK-8155197
   webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/

Problem description:
Currently we restore focus synchronously to a component if the window (which 
contains it) owns the focus. However if another window/dialog is displayed at 
the same time, the first window loses focus, (i.e. synchronous focus request 
failed) and the focus target is shifted to the next component in the focus 
traversal cycle.

Fix:
It is necessary to check the result of synchronous focus request for a 
component. If the focus request’s failed because the contained window lost 
focus, we should restore focus to this component next time when its parent 
window obtains focus.

Testing:
I ran corresponding JCK and regression tests and did not observe any new 
failures.

Thanks,
Dmitry

Re: [10] Review request for 8182043: Access to Windows Large Icons

2017-09-25 Thread Sergey Bylokhov


On 9/22/17 04:22, Alexey Ivanov wrote:

There's no way of knowing in advance.
Explorer does not restrict the size of icons (now), it's up to 
developers of a particular file handler to provide icons. Usually, 
there's only one icon with size larger than 255.


If there's the icon of the requested size, Explorer will give it to you, 
otherwise it will scale the closest available to the requested size.


Windows documentation suggests the following sizes:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn742485(v=vs.85).aspx#size_requirements 


Ok, so it means that we will support 1-128 pixels 
natively(MAX_ICON_SIZE) and others via MRI.




As for FILE_ICON_SMALL and FILE_ICON_LARGE, I'd suggest using Windows 
API to retrieve the recommended size for small and large icon size 
rather than defaulting to 16×16 and 32×32. If HiDPI is in effect, the 
icons must be larger.


But this depends from the the DPI of the screen, we cannot just request 
default FILE_ICON_SMALL/FILE_ICON_LARGE. If these constants will be 
added then we should use something like this to get correct icons:


Icon icon = getSystemIcon(file, FILE_ICON_SMALL);
Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);
or
Icon icon = getSystemIcon(file);
Icon hicon = getSystemIcon(file, icon.getIconWidth()*screenScale);
Or we can do:
Icon hicon = getSystemIcon(file, FILE_ICON_LARGE);

This means that on HiDPI screen the FILE_ICON_LARGE works in similar way 
as FILE_ICON_SMALL on non-HiDPI screen, and the meaning of the 
FILE_ICON_SMALL on HiDPI is unclear, because it is half of the correct size.


For example one of the consumer of this new API is WindowsFileView.
How the code below should be changed to work on a different screens, and 
request the proper icon?

WindowsFileChooserUI.java
1316 icon = getFileChooser().getFileSystemView().getSystemIcon(f);


--
Best regards, Sergey.

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-09-25 Thread Dmitry Markov

Hi Alexander,

Sounds reasonable. I am OK with usage of addChildWindow() in this case.

Thanks,
Dmitry
> On 25 Sep 2017, at 13:05, Alexander Zvegintsev 
>  wrote:
> 
> Hi Dmitry,
> 
> From my understanding JavaFX stage can't be easily integrated in JDK to 
> support orderWindow() approach,
> 
> addChildWindow() is a native(and the simplest) way to maintain one window 
> above other one, should be called only once.
> 
> IIUC the main concert of JDK-8080729 that child windows jumping to parent's 
> display upon focus receiving, this is not an issue with current fix,
> 
> because addChildWindow() will be called only upon dialog creation in case of 
> JavaFX-Swing interop.
> 
> Jump may happen if user want to create a child swing dialog on display other 
> than JavaFX stage's one,
> 
> but such rare scenario can be easily workarounded on a user side by calling 
> setLocation() right after setVisible() call.
> 
> So I would prefer to use addChildWindow() to make this fix as simple as 
> possible.
> 
> 
> Thanks,
> Alexander.
> 
> On 23/09/2017 21:21, Dmitry Markov wrote:
>> Hi Alexander,
>> 
>> In CPlatformWindow class you call CWrapper.NSWindow.addChildWindow() to 
>> place a window above JavaFX stage. The usage of addChilWindow() or/and 
>> removeChildWindow() may cause ‘jumping window issue’ in multi-monitor 
>> environment, see JDK-8080729 for more details.
>> 
>> To avoid possible problems in multi monitor set-up I suggest that you should 
>> replace addChildWindow() with orderWindow() or use some another approach to 
>> locate the window above the stage.
>> 
>> Thanks,
>> Dmitry
>>> On 22 Sep 2017, at 06:56, Alexander Zvegintsev 
>>>  wrote:
>>> 
>>> Hi Phil,
>>> 
>>> Please review the updated fix with reflection incorporated
>>> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/
>>> 
>>> New issue created JDK-8187803 
>>>  as JDK counterpart of 
>>> this issue.
>>> 
>>> Thanks,
>>> Alexander.
>>> 
>>> On 21/09/2017 22:25, Phil Race wrote:
 Some procedural comments :
 Since 90% of this is in AWT code, I'd have thought awt-dev should be 
 included here.
 I've added that list.
 
 And apart from needing separate bug ids, I don't see why the bug below is 
 confidential.
 
 
 I agree with what Kevin pointed out off-line that as in the dialog case, 
 the FX side
 of the code can use reflection and simply be a harmless non-functional 
 no-op
 if the SwingAccessor does not provide the new method.
 
 BTW
 264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
 should be "dd" not "d".
 
 -phil.
 
 On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:
> Hello,
> 
> please review the fix
> 
> http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/
> 
> for the issue
> 
> https://bugs.openjdk.java.net/browse/JDK-8185634
> 
>

Re: [10] Review request for 8155197: Focus transition issue

2017-09-25 Thread Dmitry Markov

Hi Semyon,

This issue and the problem addressed by 8139218 and 8159432 are slightly 
different. This one is still reproducible on latest 9 and 10 builds using the 
test case attached to the bug or regression test provided with the fix.

The problem takes place when we restore focus to a component and its parent 
window owns the focus. In this case we invoke doRestoreFocus(), (i.e. restore 
focus synchronously). If the parent window loses the focus during this 
invocation, focus request will fail and focus target will be shifted to next in 
focus traversal cycle. This case is not covered by the changes introduced by 
8139218 and 8159432.

Thanks,
Dmitry
> On 25 Sep 2017, at 15:58, Semyon Sadetsky  wrote:
> 
> Hi Dmitry,
> 
> This issue was already fixed in 9. See 8139218 & 8159432.
> 
> --Semyon
> 
> 
> On 09/23/2017 08:25 AM, Dmitry Markov wrote:
>> Hello,
>> 
>> Could you review a fix for jdk10, please?
>> 
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8155197
>>   webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/
>> 
>> Problem description:
>> Currently we restore focus synchronously to a component if the window (which 
>> contains it) owns the focus. However if another window/dialog is displayed 
>> at the same time, the first window loses focus, (i.e. synchronous focus 
>> request failed) and the focus target is shifted to the next component in the 
>> focus traversal cycle.
>> 
>> Fix:
>> It is necessary to check the result of synchronous focus request for a 
>> component. If the focus request’s failed because the contained window lost 
>> focus, we should restore focus to this component next time when its parent 
>> window obtains focus.
>> 
>> Testing:
>> I ran corresponding JCK and regression tests and did not observe any new 
>> failures.
>> 
>> Thanks,
>> Dmitry
>

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

2017-09-25 Thread Sergey Bylokhov


Looks fine.

On 9/21/17 17:39, Anton Litvinov wrote:

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?


I suggest to create a CSR, because this fix introduce some behavior 
change(it does not mean that we will make this property public).



--
Best regards, Sergey.

Re: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode

2017-09-25 Thread Sergey Bylokhov


From the AWT point of view the fix looks fine.

On 9/23/17 00:03, Prasanta Sadhukhan wrote:

Hi Sergey,

Please find modified webrev catering to DefaultKeyboardFocusManager also
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.05/

Regards
Prasanta
On 9/23/2017 7:52 AM, Sergey Bylokhov wrote:

Hi, Prasanta.

On 9/19/17 22:26, Prasanta Sadhukhan wrote:

Hi, Prasanta.
 - In this version it is unclear what is a purpose of the 
"fxCheckSequenceThread.start()". This code will start the thread and 
will continue execution, it will not wait when the thread will stop.
 - The DefaultKeyboardFocusManager also should check for 
"javafx.embed.singleThread"



Please find modified webrev catering to both comments
http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.04/


The new code in DefaultKeyboardFocusManager also will not wait when 
the thread will stop.




Regards
Prasanta


On 9/13/17 03:11, Prasanta Sadhukhan wrote:

Hi Sergey,

I have modified the fix to not use SecondaryLoop and not to create 
one thread per dispatch

http://cr.openjdk.java.net/~psadhukhan/8088132/webrev.03/

Regards
Prasanta
On 8/30/2017 11:41 AM, Sergey Bylokhov wrote:

Hi, Prasanta.
Can you please provide some description on how the SecondaryLoop 
will work when it will run on Appkit thread? Is it possible to get 
a deadlock here, since appkit will be blocked?


sequence, ie if the event is not first in sequence, then it will 
made

to
wait till it is the first event or till it is disposed.
Note that the new code (unlike lines 139-150) also waits 1 second, 
so we can get a situation when only one event will be dispatched 
per second, which is not we want to do.
I am not sure how often we create SequencedEvent but creating one 
thread per dispatch look inefficient.




Modified webrev
http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.02/

Regards
Prasanta
On 8/23/2017 9:31 PM, Sergey Bylokhov wrote:

Hi, Prasanta.

On 16.08.2017 3:33, Prasanta Sadhukhan wrote:
Now, since here FX App thread itself is the dispatch thread, we 
can

be sure the events are dispatched in sequence and dispose is

checked

below after EDT.

Why we can sure about this? If the SequencedEvents were created in

one

order but dispatch() for each were called in other order then the
sequenced will not be preserved?


I have tested with couple of singleThread testcase without any

issue.

Regards
Prasanta
On 8/14/2017 10:07 PM, Sergey Bylokhov wrote:

Hi, Prasanta, Kevin.

I have two notes.
   - Does this option is really supported? If it is supported we
should evaluate all usage of EventDispatchThread because in this
mode the dispatch thread is not EDT. For example I am not sure

that

we can skip the code which expects EventDispatchThread.
   - We have the similar pattern: 
"EventQueue.isDispatchThread() ->

cast(EventDispatchThread)" in some other places like in
DefaultKeyboardFocusManager.

-prasanta.sadhuk...@oracle.com  wrote:


Hi All,

Please review this fix
http://cr.openjdk.java.net/~psadhukhan/fx/8088132/webrev.00/
for an fx issue
https://bugs.openjdk.java.net/browse/JDK-8088132

More info in JBS.

Regards
Prasanta

















--
Best regards, Sergey.

Re: [10] Review request for 8155197: Focus transition issue

2017-09-25 Thread Sergey Bylokhov


Looks fine.

On 9/23/17 08:25, Dmitry Markov wrote:

Hello,

Could you review a fix for jdk10, please?

   bug: https://bugs.openjdk.java.net/browse/JDK-8155197
   webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/

Problem description:
Currently we restore focus synchronously to a component if the window (which 
contains it) owns the focus. However if another window/dialog is displayed at 
the same time, the first window loses focus, (i.e. synchronous focus request 
failed) and the focus target is shifted to the next component in the focus 
traversal cycle.

Fix:
It is necessary to check the result of synchronous focus request for a 
component. If the focus request’s failed because the contained window lost 
focus, we should restore focus to this component next time when its parent 
window obtains focus.

Testing:
I ran corresponding JCK and regression tests and did not observe any new 
failures.

Thanks,
Dmitry




--
Best regards, Sergey.

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-09-25 Thread Semyon Sadetsky


Hi Alexander,

On the Windows platform you've only modified the dialog native peer 
while on other platforms all window types are modified to use FX window 
as a parent. Shouldn't the frame native peer  be modified too on the 
Windows platform?


--Semyon


On 09/21/2017 10:56 PM, Alexander Zvegintsev wrote:


Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
 as JDK counterpart 
of this issue.


Thanks,
Alexander.
On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] Review request for 8155197: Focus transition issue

2017-09-25 Thread Semyon Sadetsky


Hi Dmitry,

This issue was already fixed in 9. See 8139218 & 8159432.

--Semyon


On 09/23/2017 08:25 AM, Dmitry Markov wrote:

Hello,

Could you review a fix for jdk10, please?

   bug: https://bugs.openjdk.java.net/browse/JDK-8155197
   webrev: http://cr.openjdk.java.net/~dmarkov/8155197/webrev.00/

Problem description:
Currently we restore focus synchronously to a component if the window (which 
contains it) owns the focus. However if another window/dialog is displayed at 
the same time, the first window loses focus, (i.e. synchronous focus request 
failed) and the focus target is shifted to the next component in the focus 
traversal cycle.

Fix:
It is necessary to check the result of synchronous focus request for a 
component. If the focus request’s failed because the contained window lost 
focus, we should restore focus to this component next time when its parent 
window obtains focus.

Testing:
I ran corresponding JCK and regression tests and did not observe any new 
failures.

Thanks,
Dmitry

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

2017-09-25 Thread Alexander Zvegintsev


Hi Sergey,

Thanks for catching this, this is an issue which should be addressed.

Thanks,
Alexander.

On 23/09/2017 08:01, Sergey Bylokhov wrote:

Hi, Alexander.
How can we be sure that the parent frame will not be disposed while we 
use a pointer?


long ownerWindowPtr = peer.getOverridenWindowHandle();
< Dispose the peer
if (ownerWindowPtr != 0) {
    //Place window above JavaFX stage
    CWrapper.NSWindow.addChildWindow(
    ownerWindowPtr, ptr, CWrapper.NSWindow.NSWindowAbove);
< Boom
}


On 9/21/17 22:56, Alexander Zvegintsev wrote:

Hi Phil,

Please review the updated fix with reflection incorporated
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/01/

New issue created JDK-8187803 
 as JDK counterpart 
of this issue.


Thanks,
Alexander.

On 21/09/2017 22:25, Phil Race wrote:

Some procedural comments :
Since 90% of this is in AWT code, I'd have thought awt-dev should be 
included here.

I've added that list.

And apart from needing separate bug ids, I don't see why the bug 
below is confidential.



I agree with what Kevin pointed out off-line that as in the dialog 
case, the FX side
of the code can use reflection and simply be a harmless 
non-functional no-op

if the SwingAccessor does not provide the new method.

BTW
264 inline HWND GetOverridenHWnd() { return m_overridenHwnd; }
should be "dd" not "d".

-phil.

On 09/21/2017 03:38 AM, Alexander Zvegintsev wrote:

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8185634

Re: [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

2017-09-25 Thread Alexey Ivanov

Hi Shashi,

On 25/09/2017 06:59, Shashidhara Veerabhadraiah wrote:
RE:  [10] JDK-8178361: JFileChooser does not allow to open 
folders with a double tap when using the touch screen interface

Hi Alexey, Please see below for my replies:

<<...>> <<...>> <<...>>

Thanks and regards,

Shashi

-Original Message-
From:Alexey Ivanov
Sent:Friday, September 22, 2017 5:26 PM
To: Shashidhara Veerabhadraiah 
; Sergey Bylokhov 

Cc:awt-dev@openjdk.java.net
Subject:Re:  [10] JDK-8178361: JFileChooser does not allow to 
open folders with a double tap when using the touch screen interface

Hi Shashi,

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:

> Hi Sergey, When I checked it was not working on the Java applications. 
None of the controls could take touch click events but it used to 
highlight because when we touch on the touch screen interface the 
system moves the cursor over to the touch point thereby enabling mouse 
focus events being sent.

I cannot grasp the meaning of this sentence.

What are touch click events?

*/[Shashi]/**/Below are therelatedmacros:/*

#define WM_LBUTTONDOWN  0x0201

#define WM_LBUTTONDBLCLK    0x0203

#define WM_POINTERDOWN   0x0246

*/[Shashi]/*More appropriately, touchdoubletap events.On a technical 
note,wheneverI did a double tap touch on the folder I could get 
WM_POINTERDOWN(0x0246)and none of the left button down or left button 
double click events. I have attached the proof for the same captured 
as text file(for both touch double tap and a mouse double click 
events).Please note that this behavior is seen after theremoval 
ofEnableMouseInPointer() as it is/_not_/ required anymore(Please see 
for the reply to your other email). I could not get left double click 
event but instead only the left button down events via the mouse 
double click. I think we use the time gap between the left button down 
events and then convert to a double click event internally.

Double clicks as |WM_LBUTTONDBLCLK| are never received by AWT windows 
because |CS_DOUBLE| style is not set. The number of clicks is counted in 
|WmMouseDown| and is included in |MouseEvent|.

Yet the complete picture is still unclear to me. So when you double-tap, 
you get |WM_LBUTTONDOWN|, |WM_LBUTTONUP|, and then |WM_POINTERDOWN| 
followed by |WM_POINTERUP|, right?

*/[Shashi]/**/So in a way we can conclude that after we do 
a/**/touch/**/double ta/**/p action there was no left button down 
events that we received./**/Please note that this is the behavior if 
we do a double tap touch/**/_on_/**/the file icon./*

Is the behaviour different if you double-tap on another component?

What are mouse focus events?

*/[Shashi]/**/Since there are 2 components in the file chooser. One is 
the icon and another is the file name. In the Java implementation the 
file chooser dialog has the icon 
r/**/epresentations/**/being/**/pretty small and usually it is 
difficult to exactly/**/tap/**/on the icon!! If there is/**/a/**/touch 
tap onto the file name we do receive/**/left button down and as well 
as pointer down messages./**/I have attached a file containing the 
proof of it for the same./*

It's a bit weird.
If you double-click a folder name with mouse, |JFileChooser| opens the 
folder.

If you delay the second click, |JFileChooser| initiates file name editing.
It corresponds to the behaviour of Windows Explorer for example.

When I double-tap a folder name in |JFileChooser|, it usually goes into 
name editing mode. It could be related to the fact that mouse is more 
accurate than a tap: it's easier to double-click than to double-tap. I 
mean that when you double-tap, the coordinates of the second tap could 
be /farther away/ from the first tap. Is it the case?

*/[Shashi]/**/This is actually a surprise for me and als/**/o tells me 
that the type of an icon component and the file name components are 
having different/**/behaviors/**/./**/I am not sure how I can change 
this/**/behaviorof the icon component/**/./*

<<...>>

With this fix,we can touchon all the icons as highlighted aboveand 
have the required actions being performed as expected, which 
was/_not_/happening earlier.

So the fix is not JFileChooser-specific, is it?

*/[Shashi]/**/No it is not./**/It enables the touch for all the 
components./*

You should've mentioned it in your review request.
Otherwise, it looked as if the change is |JFileChooser| specific because 
you discussed only this component.

Regards,
Alexey

Regards,

Alexey

>

> Thanks and regards,

> Shashi

>

> -Original Message-

> From: Sergey Bylokhov

> Sent: Tuesday, September 19, 2017 3:39 AM

> To:shashidhara.veerabhadra...@oracle.com>> 
Shashidhara

> Veerabhadraiah 
>

>

FW: [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

2017-09-25 Thread Shashidhara Veerabhadraiah

Hi Alexey, Please see below for my replies:

[Attachments will be shared upon request as they are of considerable size and 
cannot be sent to AWT dev group because of the email size limitation.]

Thanks and regards,
Shashi

-Original Message-
From: Alexey Ivanov 
Sent: Friday, September 22, 2017 5:26 PM
To: Shashidhara Veerabhadraiah < HYPERLINK 
"mailto:shashidhara.veerabhadra...@oracle.com; 
shashidhara.veerabhadra...@oracle.com>; Sergey Bylokhov < HYPERLINK 
"mailto:sergey.bylok...@oracle.com; sergey.bylok...@oracle.com>
Cc:  HYPERLINK "mailto:awt-dev@openjdk.java.net; awt-dev@openjdk.java.net
Subject: Re:  [10] JDK-8178361: JFileChooser does not allow to open 
folders with a double tap when using the touch screen interface

Hi Shashi,

On 19/09/2017 04:35, Shashidhara Veerabhadraiah wrote:
> Hi Sergey, When I checked it was not working on the Java applications. None 
> of the controls could take touch click events but it used to highlight 
> because when we touch on the touch screen interface the system moves the 
> cursor over to the touch point thereby enabling mouse focus events being sent.

I cannot grasp the meaning of this sentence.

What are touch click events?
[Shashi] Below are the related macros:
#define WM_LBUTTONDOWN  0x0201
#define WM_LBUTTONDBLCLK0x0203

#define WM_POINTERDOWN   0x0246

[Shashi]  More appropriately, touch double tap events. On a technical note, 
whenever I did a double tap touch on the folder I could get 
WM_POINTERDOWN(0x0246) and none of the left button down or left button double 
click events. I have attached the proof for the same captured as text file(for 
both touch double tap and a mouse double click events). Please note that this 
behavior is seen after the removal of EnableMouseInPointer() as it is not 
required anymore(Please see for the reply to your other email). I could not get 
left double click event but instead only the left button down events via the 
mouse double click. I think we use the time gap between the left button down 
events and then convert to a double click event internally.
[Shashi] So in a way we can conclude that after we do a touch double tap action 
there was no left button down events that we received. Please note that this is 
the behavior if we do a double tap touch on the file icon.

What are mouse focus events?
[Shashi] Since there are 2 components in the file chooser. One is the icon and 
another is the file name. In the Java implementation the file chooser dialog 
has the icon representations being pretty small and usually it is difficult to 
exactly tap on the icon!! If there is a touch tap onto the file name we do 
receive left button down and as well as pointer down messages. I have attached 
a file containing the proof of it for the same.

[Shashi] This is actually a surprise for me and also tells me that the type of 
an icon component and the file name components are having different behaviors. 
I am not sure how I can change this behavior of the icon component.
With this fix, we can touch on all the icons and have the required actions 
being performed as expected, which was not happening earlier.

So the fix is not JFileChooser-specific, is it?
[Shashi] No it is not. It enables the touch for all the components.

Regards,
Alexey

>
> Thanks and regards,
> Shashi
>
> -Original Message-
> From: Sergey Bylokhov
> Sent: Tuesday, September 19, 2017 3:39 AM
> To:  HYPERLINK "mailto:shashidhara.veerabhadra...@oracle.com; 
> shashidhara.veerabhadra...@oracle.com >> Shashidhara 
> Veerabhadraiah < HYPERLINK "mailto:shashidhara.veerabhadra...@oracle.com; 
> shashidhara.veerabhadra...@oracle.com>
> Cc:  HYPERLINK "mailto:awt-dev@openjdk.java.net; awt-dev@openjdk.java.net
> Subject: Re:  [10] JDK-8178361: JFileChooser does not allow 
> to open folders with a double tap when using the touch screen 
> interface
>
> Hi, Shashi.
> Why the bug is JFileChooser specific?
> Does it means that it works for other elements(buttons/lists/menu/etc)?
>
> On 9/18/17 08:58, Shashidhara Veerabhadraiah wrote:
>> Hi All, Please review this software changes for the /_enhancement_/ 
>> JDK-8178361.
>>
>> Issue: Request was filed to enable the touch event processing for 
>> Java client applications.
>>
>> Fix: Windows platform offers 'pointer' implementation thro' which one 
>> can tap for the touch inputs as well. A typical 'pointer' function 
>> may contain touch, pen, touch pad or mouse inputs. This allows for a 
>> uniform input processing though the event source may defer. This fix 
>> enables the 'touch' events(via TOUCH pointer) to be passed to the 
>> components using the other type of pointer 'mouse'. Essentially there 
>> is a conversion put in place to convert a touch event input into a 
>> left click mouse event. I think this is the right thing to do 
>> considering desktop scenarios to which the typical Java applications 
>> that gets exposed to. This is also the same behavior on my

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

Re: [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

Re: [10] Review request for 8155197: Focus transition issue

Re: [10] Review request for 8182043: Access to Windows Large Icons

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

Re: [10] Review request for 8155197: Focus transition issue

Re: [10] Review request for 8166772: Touch keyboard is not shown for text components on a screen touch

Re: [10] RFR JDK-8088132:[Swing, singleThread] ClassCastException in nested event loop when showing multiple message dialogs in SwingNode

Re: [10] Review request for 8155197: Focus transition issue

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

Re: [10] Review request for 8155197: Focus transition issue

Re: [10] Review request for 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

Re: [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

FW: [10] JDK-8178361: JFileChooser does not allow to open folders with a double tap when using the touch screen interface

15 matches

Site Navigation

Mail list logo

Footer information