JavaFX SWT and Swing-Interopt

[Kevin Rushforth]

> ...there are no EA-Builds of Java8 available anymore (Looks like Oracle does not want people to test fixes for upcoming 8-update anymore)

EA builds of JDK 8u192 were supposed to be published last week, but 
there was a glitch. I hope it will be fixed soon.

Having said that, I see that the issue Prasanta mentioned was fixed in 
JDK 8u172, but I don't know whether your issue is the same. What 
platform(s) do you see this bug on?

-- Kevin


On 7/31/2018 4:08 AM, Tom Schindl wrote:
> Hi,
>
> I give it a try but from the bug description and discussion I would have
> assumed it deals with the opposite problems (Opening a Swing-Dialog from
> an JavaFX-Application who uses Swing-Node).
>
> I also studied the code to see if how you make a JavaFX-Stage having a
> different owner but I could only find changes to AWT deal with this.
>
> Anyways I'll try to get it the latest master running. The issue states
> that it is fixed in 8u182 but only 8u181 is available and there are no
> EA-Builds of Java8 available anymore (Looks like Oracle does not want
> people to test fixes for upcoming 8-update anymore)
>
> Tom
>
> On 31.07.18 11:21, Prasanta Sadhukhan wrote:
>> Hi Tom,
>>
>> I am not able to see the problem in latest workspace. I believe this
>> issue is already fixed by JDK-8185634.
>>
>> Regards
>> Prasanta
>> On 7/31/2018 1:16 PM, Tom Schindl wrote:
>>> Hi,
>>>
>>> In one of our customers application we have major problems when
>>> embedding JavaFX into SWT (but from my tests the situation is equal for
>>> Swing).
>>>
>>> In the end all windows (most commonly popup-windows) are affected
>>> because they don't have a parent-window assigned and so they can be
>>> hidden by the window embedding them - if the window opened is Modal like
>>> eg the one from ColorPicker the JavaFX UI is also blocked.
>>>
>>> To see what I mean just use this snippet below and do the following:
>>> * Bring up the DropDown-List
>>> * Bring up the custom color dialog
>>> * Click somewhere in the JFrame
>>>
>>> You notice the following:
>>> * JavaFX Window is moved behind Swing-Window
>>> * JavaFX UI is blocked
>>>
>>>> package test;
>>>>
>>>> import javax.swing.JFrame;
>>>>
>>>> import javafx.application.Platform;
>>>> import javafx.embed.swing.JFXPanel;
>>>> import javafx.geometry.Pos;
>>>> import javafx.scene.Scene;
>>>> import javafx.scene.control.ColorPicker;
>>>> import javafx.scene.layout.BorderPane;
>>>>
>>>> public class TestSwingInterop extends JFrame {
>>>>      
>>>>      public TestSwingInterop() {
>>>>          setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
>>>>          final JFXPanel fxPanel = new JFXPanel();
>>>>           add(fxPanel);
>>>>                    Platform.runLater(new Runnable() {
>>>>               @Override
>>>>               public void run() {
>>>>                   initFX(fxPanel);
>>>>               }
>>>>           });
>>>>      }
>>>>      
>>>>      private static void initFX(JFXPanel fxPanel) {
>>>>           // This method is invoked on JavaFX thread
>>>>           Scene scene = createScene();
>>>>           fxPanel.setScene(scene);
>>>>       }
>>>>      
>>>>      private static Scene createScene() {
>>>>          ColorPicker picker = new ColorPicker();
>>>>          BorderPane.setAlignment(picker, Pos.TOP_LEFT);
>>>>          BorderPane p = new BorderPane(picker);
>>>>         
>>>>          return new Scene(p);
>>>>      }
>>>>
>>>>      public static void main(String[] args) {
>>>>          TestSwingInterop s = new TestSwingInterop();
>>>>          s.setBounds(100, 100, 1000, 800);
>>>>          s.setVisible(true);
>>>>      }
>>>> }
>>> I've tested this on Java8 and Java9 but didn't had a chance to run it on
>>> the latest master.
>>>
>>> The problem is that the newly created JavaFX windows don't have the
>>> Native-Window as their parent but the EmbeddedStage (who is not bound to
>>> a native-window handle). It looks like EmbeddedStage has already been
>>> prepared (see getRawHandle() : long) to support something like that in
>>> future but com.sun.glass.ui.Window and its subclasses have never been
>>> extend to create a window based on a pure long-pointer.
>>>
>>> The only exception and the reason I guess the strategy would work was
>>> used for Applets.
>>>
>>> Before diving deeper into this I wanted to get a feedback from people
>>> who know things better: Does the strategy of passing along the window
>>> pointer (eg from SWT, don't know about Swing yet) to Glass and using it
>>> as the parent pointer sound like a proper idea?
>>>
>>> Tom
>>>