Re: CFV: New OpenJFX Committer: Rajath Kamath

[Semyon Sadetsky]

Vote: yes

--Semyon


On 02/12/2018 02:02 PM, Kevin Rushforth wrote:

I hereby nominate Rajath Kamath [1] to OpenJFX Committer.

Rajath is a member of JavaFX team at Oracle, who has contributed 11 
changesets [2][3] to OpenJFX.


Votes are due by February 26, 2018.

Only current OpenJFX Committers [4] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [5]. Nomination to a 
project Committer is described in [6].


Thanks.

-- Kevin

[1] http://openjdk.java.net/census#rkamath

[2] 
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20=author%28rkamath%29
[3] 
http://hg.openjdk.java.net/openjfx/jfx-dev/rt/log?revcount=20=rajath.kamath


[4] http://openjdk.java.net/census#openjfx

[5] http://openjdk.java.net/bylaws#lazy-consensus

[6] http://openjdk.java.net/projects#project-committer

Re: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing dialogs appearing behind main stage

[Semyon Sadetsky]

Hi Phil, Dipak,

The 8021961 fix was about invisible parent window. The current fix is 
independent from it so the change looks good.


--Semyon

On 01/17/2018 09:48 PM, Dipak Kumar wrote:

Hi Semyon,

Could you please review the changes (also have a look at Phil's comment in 
trailing mail) and let me know your comments.

Thanks Kevin and Phil. I have incorporated the changes suggested for unit tests 
in JavaFx side. Request you to have a look.

Please find updated webrev at - 
http://cr.openjdk.java.net/~dkumar/8185634/webrev.01/ .

Thanks,
Dipak

-Original Message-
From: Kevin Rushforth
Sent: Thursday, January 18, 2018 3:21 AM
To: Phil Race 
Cc: Dipak Kumar ; openjfx-dev@openjdk.java.net; 
awt-...@openjdk.java.net
Subject: Re: [8u-Backport] Review request for 8185634, 8187803 : Java Fx-Swing 
dialogs appearing behind main stage

I think you mean https://bugs.openjdk.java.net/browse/JDK-8187803 for the 
AWT/Swing side...

-- Kevin


Phil Race wrote:

The AWT/Swing side of this needs to be bug
https://bugs.openjdk.java.net/browse/JDK-8185634

One thing I notice is that in XWindowPeer.java the calculation for the
value of transientForWindow is different .. because you don't have the
fix for
https://bugs.openjdk.java.net/browse/JDK-8021961 :
"setAlwaysOnTop doesn't behave correctly in Linux/Solaris under
certain scenarios"

Do you first need to backport that too ? Maybe Semyon (who authored
that fix) can say whether it matters ..

-phil.

On 01/12/2018 02:12 AM, Dipak Kumar wrote:

Hi All,

  
Please review the below patch (for 8u-backport) -


  
Webrev : http://cr.openjdk.java.net/~dkumar/8185634/webrev.00/


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

  
Thanks,


Dipak

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

[Semyon Sadetsky]

Looks good.

--Semyon


On 11/07/2017 06:59 PM, Alexander Zvegintsev wrote:


HI Semyon,

Please see my answer to Dmitry


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 08/11/2017 02:45, Semyon Sadetsky wrote:


Hi Alexander,

In CPlatformWindow.java change you used addChildWindow(), but we get 
rig of addChildWindow() in 8080729 and start to manage windows order 
on java side. Can you test that this change doesn't cause any 
ordering issues with modal and non-modal child and sibling windows on 
mac?


--Semyon

On 11/07/2017 10:11 AM, Alexander Zvegintsev wrote:


Hi Sergey,

I am not able to crash it on several platforms, except one case:

if we are terminating JavaFX application while EDT processing some 
long task. But it is unrelated to the fix and reproducible on 
current builds.


I've filed a separate bug JDK-8190329 
<https://bugs.openjdk.java.net/browse/JDK-8190329>.


Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows? 
It will not, Windows already fixed by JDK-8088395 
<https://bugs.openjdk.java.net/browse/JDK-8088395>



Test added:
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/05/
Thanks,
Alexander.
On 13/10/2017 01:14, Sergey Bylokhov wrote:

Looks fine.
I am not sure but it looks like the fix has an assumption that the 
CPlatformWindow.setVisible() code will be executed on EDT/Appkit 
but it is not the case. This code can be executed on any 
thread(intentionally for crash), and it will be good to check that 
it works as expected by some stress test which will try to force 
the possible crash: 4 threads:

 - show/dispose Swing Node
 - show/dispose Dialog1/2/3 using different timeouts

Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows?


On 10/10/2017 13:54, Kevin Rushforth wrote:

Note that there is now a 04 version.

It looks good to me, although someone more familiar with AWT 
should also check the AWT changes.


We will need a test program for this (as a follow-on issue if not 
now).


-- Kevin


Alexander Zvegintsev wrote:

Please review the updated version

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/
Now we are postponing actual window closing, it happens only 
after we ensure that native window pointer is valid on Swing side.


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 
<https://bugs.openjdk.java.net/browse/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 8185634, 8185634: Java Fx-Swing dialogs appearing behind main stage

[Semyon Sadetsky]

Hi Alexander,

In CPlatformWindow.java change you used addChildWindow(), but we get rig 
of addChildWindow() in 8080729 and start to manage windows order on java 
side. Can you test that this change doesn't cause any ordering issues 
with modal and non-modal child and sibling windows on mac?


--Semyon

On 11/07/2017 10:11 AM, Alexander Zvegintsev wrote:


Hi Sergey,

I am not able to crash it on several platforms, except one case:

if we are terminating JavaFX application while EDT processing some 
long task. But it is unrelated to the fix and reproducible on current 
builds.


I've filed a separate bug JDK-8190329 
.


Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows? 
It will not, Windows already fixed by JDK-8088395 




Test added:
http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/05/
Thanks,
Alexander.
On 13/10/2017 01:14, Sergey Bylokhov wrote:

Looks fine.
I am not sure but it looks like the fix has an assumption that the 
CPlatformWindow.setVisible() code will be executed on EDT/Appkit but 
it is not the case. This code can be executed on any 
thread(intentionally for crash), and it will be good to check that it 
works as expected by some stress test which will try to force the 
possible crash: 4 threads:

 - show/dispose Swing Node
 - show/dispose Dialog1/2/3 using different timeouts

Will the current fix cover the native dialogs like 
FileDialog/PrintDialog on linux and windows?


On 10/10/2017 13:54, Kevin Rushforth wrote:

Note that there is now a 04 version.

It looks good to me, although someone more familiar with AWT should 
also check the AWT changes.


We will need a test program for this (as a follow-on issue if not now).

-- Kevin


Alexander Zvegintsev wrote:

Please review the updated version

http://cr.openjdk.java.net/~azvegint/jdk/10/8185634/02/
Now we are postponing actual window closing, it happens only after 
we ensure that native window pointer is valid on Swing side.


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: CFV: New OpenJFX Committer: Ambarish Rapte

[semyon . sadetsky]

Vote: YES

--Semyon

On 10/31/17 1:18 PM, Kevin Rushforth wrote:

I hereby nominate Ambarish Rapte [1] to OpenJFX Committer.

Ambarish is a member of JavaFX team at Oracle, who has contributed 10 
changesets [2][3] to OpenJFX.


Votes are due by November 14, 2017.

Only current OpenJFX Committers [4] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [5]. Nomination to a 
project Committer is described in [6].


Thanks.

-- Kevin

[1] http://openjdk.java.net/census#arapte

[2] 
http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20=author%28arapte%29

[3] http://hg.openjdk.java.net/openjfx/10-dev/rt/rev/f7d38650fa15

[4] http://openjdk.java.net/census#openjfx

[5] http://openjdk.java.net/bylaws#lazy-consensus

[6] http://openjdk.java.net/projects#project-committer

Re: CFV: New OpenJFX Committer: Prasanta Sadhukhan

[Semyon Sadetsky]

Vote: YES


On 9/27/2017 6:10 PM, Kevin Rushforth wrote:

I hereby nominate Prasanta Sadhukhan [1] to OpenJFX Committer.

Prasanta is a member of JavaFX team at Oracle, who has contributed 12 
changesets [2] to OpenJFX.


Votes are due by October 11, 2017.

Only current OpenJFX Committers [3] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [4]. Nomination to a 
project Committer is described in [5].


Thanks.

-- Kevin

[1] http://openjdk.java.net/census#psadhukhan

[2] 
http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=20=author%28psadhukhan%29


[3] http://openjdk.java.net/census#openjfx

[4] http://openjdk.java.net/bylaws#lazy-consensus

[5] http://openjdk.java.net/projects#project-committer

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

[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: CFV: New OpenJFX Committer: Ajit Ghaisas

[Semyon Sadetsky]

Vote: YES

--Semyon


On 05/26/2017 05:20 AM, Kevin Rushforth wrote:

I hereby nominate Ajit Ghaisas [1] to OpenJFX Committer.

Ajit is a member of JavaFX team at Oracle, who has contributed 10 
changesets to OpenJFX. A list of these changesets is available by the 
following link:


http://hg.openjdk.java.net/openjfx/10-dev/rt/log?revcount=40=author%28aghaisas%29 



Votes are due by June 9, 2017.

Only current OpenJFX Committers [2] are eligible to vote on this 
nomination. Votes must be cast in the open by replying to this mailing 
list.


For Lazy Consensus voting instructions, see [3]. Nomination to a 
project Committer is described in [4].


Thanks.

-- Kevin

[1] http://openjdk.java.net/census#aghaisas

[2] http://openjdk.java.net/census#openjfx

[3] http://openjdk.java.net/bylaws#lazy-consensus

[4] http://openjdk.java.net/projects#project-committer

Re: [10] Review request for 8179597: Handle cut and paste of 1, 2 and 4 byte characters

[Semyon Sadetsky]

yes, that was a typo. Actually, the fix is for 10.

--Semyon

On 5/8/2017 8:20 AM, Kevin Rushforth wrote:


Please review the fix for jfx9: 


I presume this is a typo and you meant to say jfx10?

-- Kevin


Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8179597

webrev: http://cr.openjdk.java.net/~ssadetsky/8179597/webrev.00/

--Semyon

[10] Review request for 8179597: Handle cut and paste of 1, 2 and 4 byte characters

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8179597

webrev: http://cr.openjdk.java.net/~ssadetsky/8179597/webrev.00/

--Semyon

Re: [10] Review request for 8176844: Menus not always selected properly with GTK 3

[Semyon Sadetsky]

On 04/05/2017 11:23 AM, David Hill wrote:


On 4/5/17, 12:52 PM, Semyon Sadetsky wrote:

Okay. Thank you to you all!

The root cause why we need to add sync is a new way to grab/ungrab 
focus used in the GTK3 glass implementation.


The GTK2 way to grab/ungrab is still applicable in GTK3 though it is 
deprecated. But the used GTK3 grab/ungrab is deprecated as well since 
version 3.20 (Ubuntu 16.04 LTS has 3.18 assigned, but newer OS 
versions will come with higher number).


David, do you think we could use the same GTK2 grab/ungrab for GTK3 
to avoid sync?

I am OK with that.

I could not make the new grab/ungrab working without sync. So, I 
fall-back to the GTK2 way to grab/ungrab:


http://cr.openjdk.java.net/~ssadetsky/8176844/webrev.01/

--Semyon

Re: [10] Review request for 8176844: Menus not always selected properly with GTK 3

[Semyon Sadetsky]

Okay. Thank you to you all!

The root cause why we need to add sync is a new way to grab/ungrab focus 
used in the GTK3 glass implementation.


The GTK2 way to grab/ungrab is still applicable in GTK3 though it is 
deprecated. But the used GTK3 grab/ungrab is deprecated as well since 
version 3.20 (Ubuntu 16.04 LTS has 3.18 assigned, but newer OS versions 
will come with higher number).


David, do you think we could use the same GTK2 grab/ungrab for GTK3 to 
avoid sync?


Also, I found some other potential issues in the GTK3 implementation.

1. gdk_device_manager_get_client_pointer() is used for getting pointer 
position and for D pointer grab, and the documentation to this 
function says:


You should use this function seldomly, only in code that isn’t triggered 
by aGdkEvent 
<https://developer.gnome.org/gdk3/stable/gdk3-Event-Structures.html#GdkEvent>and 
there aren’t other means to get a meaningfulGdkDevice 
<https://developer.gnome.org/gdk3/stable/GdkDevice.html>to operate on.


but we are using it in processing of GDK_BUTTON_PRESS, 
GDK_BUTTON_RELEASE and GDK_DRAG_STATUS events.


2. GList obtained by gdk_device_manager_list_devices() during 
grab/ungrab operations is not freed,  so it causes memory leak.


I will file bug for 1. and for 2. if the new GDK3 grab/ungrab will be 
preserved.


--Semyon


On 04/04/2017 04:53 PM, Kevin Rushforth wrote:
I raised the same concern in the JBS issue, especially for mouse and 
keyboard events.


-- Kevin


Jim Graham wrote:
I don't think I was specifically involved in AWT fixes for that 
issue, but the concerns that David raises are all valid and Phil 
correctly points out that this is much worse in a network display 
environment...


...jim

On 4/4/17 3:53 PM, Philip Race wrote:

AWT used to have really bad at X11 remote display and
it was looked at a few times and I think it was improved
noticeably when we could get rid of  "round trip" requests.
I think Jim had a hand in some of that work.

So I am sure a round trip - or similar - is bad for performance.

If you want to measure the effect of such change, remote display to
your desktop from a machine in a geographically distant site.

It is the latency that kills performance, not the bandwidth.

-phil.

On 4/4/17, 3:43 PM, David Hill wrote:

On 4/4/17, 1:27 PM, Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8176844

webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/

--Semyon



Semyon,

I have been sitting here for a while thinking about adding
gdk_display_sync(gdk_display_get_default());

I can see why this might address many issues, as it flushes the 
pipeline and waits for the X11 server to catch up.
That is balanced out by a historical distrust of using XSync in any 
situation where the consequences.


Part of me thinks it is minimal overhead though, the other part 
does not like stalling the asynchronous X11 design.


The other part of me would like to use this only for the window 
events that need it, instead of all of them.


and I found this in hte GTK docs:
gdk_events_pending ()
Waits for a GraphicsExpose or NoExpose event from the X server. 
This is used in the GtkText and GtkCList widgets in
GTK+ to make sure any GraphicsExpose events are handled before the 
widget is scrolled.


so perhaps this should be used in some cases (like setVisible).

sigh.

Will try to make up my mind tomorrow.

Dave.

Re: [10] Review request for 8176844: Menus not always selected properly with GTK 3

[Semyon Sadetsky]

Sorry. The fix is for JFX *10*.


On 04/04/2017 10:27 AM, Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8176844

webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/

--Semyon

[10] Review request for 8176844: Menus not always selected properly with GTK 3

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8176844

webrev: http://cr.openjdk.java.net/~ssadetsky/8176844/

--Semyon

[9] Review request for 8175822: Pulldown position regression and not painting correctly tooltips regression

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8175822

webrev: http://cr.openjdk.java.net/~ssadetsky/8175822/webrev.00/

--Semyon

[9] Review request for 8175204: Linux: Dialog windows come up 1-pixel wide

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8175204

webrev: http://cr.openjdk.java.net/~ssadetsky/8175204/webrev.00/

--Semyon

[9] Review request for 8175205: Linux: Stage initially in full-screen mode not shown when exiting full-screen

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8175205

webrev: http://cr.openjdk.java.net/~ssadetsky/8175205/webrev.00/

--Semyon

[9] Review request for 8174154: NPE in JFXPanel$HostContainer#setEmbeddedStage

[Semyon Sadetsky]

Hello Kevin,

Please review fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8174154

webrev: http://cr.openjdk.java.net/~ssadetsky/8174154/webrev.00/

--Semyon

[9] Review request for 8173901: Linux: Position of Stage is not restored after exiting full screen

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8173901

webrev: http://cr.openjdk.java.net/~ssadetsky/8173901/webrev.00/

--Semyon

[9] Review request for 8090249: [Linux] Restoring owner stage after minimize does not restore position of child stage

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8090249

webrev: http://cr.openjdk.java.net/~ssadetsky/8090249/webrev.00/

--Semyon

[9] Review request for 8152421: After initing the modality of a non-primary stage to MODAL, closing that stage causes the primary stage to become non-resizable

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8152421

webrev: http://cr.openjdk.java.net/~ssadetsky/8152421/webrev.01/

Set window enabled logic is updated to restore window resizability 
correctly.


--Semyon

[9] Review request for 8172554: [macos] deadlock on JFXPanel startup

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8172554

webrev: http://cr.openjdk.java.net/~ssadetsky/8172554/webrev.01/

JFXPanel initializes JFX on EDT as result EDT and Toolkit thread may 
block each other. The proposed solution do not block EDT while JFX is 
initialized. See other details in the bug.


--Semyon

[9] Review request for 8172096: SwingNode, Linux: certain mnemonics don't work on Unity

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8172096

webrev: http://cr.openjdk.java.net/~ssadetsky/8172096/webrev.00/

The details are in the bug.

--Semyon

[9] Review request for 8171330: Issues with transparent stage and GTK

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8171330

webrev: http://cr.openjdk.java.net/~ssadetsky/8171330/webrev.00/

By the logic of scene painting the compositing method should be "source 
over destination" in both cases GTK2 and GTK3.


--Semyon

[9] Review request for 8166147: Ubuntu 16.04: expandable content goes outside of the alert dialog

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8166147

webrev: http://cr.openjdk.java.net/~ssadetsky/8166147/webrev.00/

XLib size requests and hints was mixed up with GTK ones.

--Semyon

[9] Review request for 8166414: Scene returns incorrect coordinates

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8166414

webrev: http://cr.openjdk.java.net/~ssadetsky/8166414/webrev.00/

According to GTK iib documentation on X11 WMs the 
gtk_window_get_position() function doesn't return the exact window 
position coordinates but a guessed position where WM should place the 
decorated window by taking into account gravity attribute and extents. 
There are situations when algorithm used for guessing the window 
position doesn't produce good result. This may depend on the platform WM 
implementation.


As a fix I suggest to use window extent information which is collected 
on frame extent property notification. To get the correct position X and 
Y event coordinates should be decreased by top and left extent values 
correspondingly.


--Semyon

[9] Review request for 8151170: WINDOW_MODAL dialog does not popup when restoring iconified owner window, which causes application freeze

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8151170

webrev: http://cr.openjdk.java.net/~ssadetsky/8151170/webrev.00/

Win32 API ::GetWindowRect() call returns fake -32000,-32000 location for 
iconified window. Solution: skip WM_MOVE if window iconified.


--Semyon

Re: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas

[Semyon Sadetsky]

On 23.11.2016 19:29, Tom Schindl wrote:


Hi,

Ok. I think I got it:

a) if SWT is loaded first (which is th 99% case I guess) then you are
finding out that you need to run with gtk2 or gtk3 by finding out
what gtk libs are already loaded (webref
http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.00/)

b) if JavaFX is loaded before SWT but SWT is on the classpath then you
try to findout what SWT will load and align with that (webref
http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.01/)

If that is correct all my concerns are addressed! There's one very
unlikely case:

a) one creates an OSGi-Application
It is possible that SWT lib is added to an another OSGi bundle classpath 
which is not accessible. Since all OSGi bundles share the same process 
it may cause the GTK version conflict. I think we cannot resolve this 
issue for OSGi and for all other custom ClassLoader hierarchies.


--Semyon

b) one loads a JavaFX UI
c) loads an SWT-UI

Both webrefs won't address this case if not mistaken, but I have never
seen an application like that ;-)

Tom

On 23.11.16 13:32, Semyon Sadetsky wrote:

On 11/23/2016 12:38 PM, Tom Schindl wrote:


  From looking at the code I doubt your fix will work reliably in a
OSGi-Environment who is the Main deployment scenario for SWT and hence
FXCanvas!

For sure you won't find the SWT-Library on the SystemClassloader and
whether you find it on the Thread-ContextClassloader is just gambling!

The only area you for sure can detect the swt-library are the
swt-fx.jar-Classes because those are guaranteed to be loaded with a
classloader who can look up SWT-Libary classes like
"org.eclipse.swt.internal.gtk.OS"

What is swt-fx.jar? Maybe you meant javafx-swt.jar?

BTW: Is the statement below really correct?

 in JFX embeded into SWT scenarios JFX loads GTK primarily ...

If you create an instance of FXCanvas SWT must have been loaded already
(You need to pass a parent Composite) so the native gtk-libs are there
already loaded.

That's right concern. Actually the fix covers the scenario when swt.jar
is on the classpath and may be potentially loaded in future with another
GTK version (which will cause the process crash). The rest scenarios are
covered by the 8156491 fix which I just posted for review.

--Semyon

Tom

On 22.11.16 14:51, Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8157002

webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/

In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK
version cannot be detected using the check for the loaded native library
version.

The fix proposes a way to detect if GTK version of swt.jar library is
available on the classpath and tries to get the GTK version from SWT lib
internal java classes.

--Semyon

Re: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas

[Semyon Sadetsky]

On 11/23/2016 12:38 PM, Tom Schindl wrote:


 From looking at the code I doubt your fix will work reliably in a
OSGi-Environment who is the Main deployment scenario for SWT and hence
FXCanvas!

For sure you won't find the SWT-Library on the SystemClassloader and
whether you find it on the Thread-ContextClassloader is just gambling!

The only area you for sure can detect the swt-library are the
swt-fx.jar-Classes because those are guaranteed to be loaded with a
classloader who can look up SWT-Libary classes like
"org.eclipse.swt.internal.gtk.OS"

What is swt-fx.jar? Maybe you meant javafx-swt.jar?


BTW: Is the statement below really correct?

 in JFX embeded into SWT scenarios JFX loads GTK primarily ...

If you create an instance of FXCanvas SWT must have been loaded already
(You need to pass a parent Composite) so the native gtk-libs are there
already loaded.
That's right concern. Actually the fix covers the scenario when swt.jar 
is on the classpath and may be potentially loaded in future with another 
GTK version (which will cause the process crash). The rest scenarios are 
covered by the 8156491 fix which I just posted for review.


--Semyon


Tom

On 22.11.16 14:51, Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8157002

webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/

In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK
version cannot be detected using the check for the loaded native library
version.

The fix proposes a way to detect if GTK version of swt.jar library is
available on the classpath and tries to get the GTK version from SWT lib
internal java classes.

--Semyon

[9] Review request for 8156491: Autodetect GTK version for JFX

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8156491

webrev: http://cr.openjdk.java.net/~ssadetsky/8156491/webrev.00/

The fix implements the autodetect feature which protects JFX Glass 
toolkit from the crash caused by loading dynamic libs from different GTK 
versions into the same process on Linux platform.


--Semyon

Re: [9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas

[Semyon Sadetsky]

Thanks, Doychin.

The webrev is updated: 
http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.01/


--Semyon


On 11/23/2016 10:15 AM, Doychin Bondzhev wrote:

Hi,

I think this line is incorrect:

if (ver < 2 && ver > 3) {

It should be || instead of &&

On 22.11.2016 г. 15:51 ч., Semyon Sadetsky wrote:

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8157002

webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/

In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK
version cannot be detected using the check for the loaded native library
version.

The fix proposes a way to detect if GTK version of swt.jar library is
available on the classpath and tries to get the GTK version from SWT lib
internal java classes.

--Semyon

[9] Review request for 8157002: Toggle gtk version if SWT used via FXCanvas

[Semyon Sadetsky]

Hello Kevin & David,

Please review the fix for jfx9:

bug: https://bugs.openjdk.java.net/browse/JDK-8157002

webrev: http://cr.openjdk.java.net/~ssadetsky/8157002/webrev.00/

In JFX embeded into SWT scenarios JFX loads GTK primarily. So SWT GTK 
version cannot be detected using the check for the loaded native library 
version.


The fix proposes a way to detect if GTK version of swt.jar library is 
available on the classpath and tries to get the GTK version from SWT lib 
internal java classes.


--Semyon

[9] Review request for 8169309: Migrate SwingNode to the new float API of JLightweightFrame

[Semyon Sadetsky]

Hello Kevin & Jim,

Please review the fix for jfx9:

webrev: http://cr.openjdk.java.net/~ssadetsky/8169309/webrev.00/

bug: https://bugs.openjdk.java.net/browse/JDK-8153522

--Semyon

[9] Review Request for 8162551: SwingNode scaling doesn't work

[Semyon Sadetsky]

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8162551

webrev: http://cr.openjdk.java.net/~ssadetsky/8162551/webrev.00/


Upscaling is not needed to send coordinates to sun.swing.JLightweightFrame.

--Semyon