Artem Ananiev artem.ananiev at oracle.com
Mon Dec 24 07:06:51 PST 2012

On 12/24/2012 6:25 PM, Scott Palmer wrote:
> On 2012-12-24, at 5:18 AM, Anthony Petrov <anthony.petrov at oracle.com>
> wrote:
>> On 12/21/2012 18:54, Scott Palmer wrote:
>> ...
>>> Anyway.. the blocking can be dealt with in the application code
>>> if need be (make the Dialog modeless and block the panel via
>>> other means).  It isn't even the issue.  It is the Window
>>> hierarchy that is the issue.  Dialogs should never go behind
>>> their parent window.  That's the only bug I would be trying to
>>> address for now.
>> The only way to implement this reliably is to use the handle to the
>> native Swing window as an owner for the FX dialog, which is not
>> currently possible unfortunately.
>> I understand the need for this completely. However, I doubt this
>> possibility would be useful for FX in the long run, especially
>> given that workarounds exist.
> What is the workaround for file choosers?  The swing version crashes
> the JVM on windows when you try to sort in details view - a major bug
> that our testers are very unhappy about.

What is the bug number, where the crash is described?

> Tool tips?  ColorPicker? Context menus? Any popup window...  There
> are several issues with these not going away when they should or
> going behind the parent window.

Have you tried the latest 8 builds? The fix for RT-24632 should address 
popup windows. It was not backported to 2.2.x

> The workaround is don't use JavaFX, which sort of makes migration of
> Swing apps an all or nothing deal.  When we hit these issues during
> piece-wise migration it becomes a bit scarier to commit to the full
> migration.
> I suspect the parent window issue is the root of a lot of JFXPanel
> problems.  If JAWT can be used to get a proper parent window for the
> Scene I'm hoping it will go a long way.  If enough of the toolkit
> code is open source I would consider attempting a patch myself.

I provided comments about JAWT in previous emails. I don't say it's not 
a solution, I say it requires much more code to work reliably than one 
can expect.

>> For example, you could use a Swing modal dialog to achieve the same
>> result - just put your modal FX content into another JFXPanel and
>> embed it into the JDialog.
> That is the approach we are going with for now.
>> Or, as you're suggesting above, you could disable the panel
>> manually which wouldn't fix the z-order but at least would provide
>> some kind of modality.
> We don't have a problem with modality at the moment.
>> A third approach is to get rid of the JFXPanel altogether and put
>> your FX content into a real FX top-level window.
> In other words a full JavaFX app without Swing... this is what we are
> working towards.
> Happy holidays,

Merry Cristmas and Happy New Year :)



> Scott >
>> --
>> best regards,
>> Anthony
>>> Scott
>>> On 2012-12-21, at 8:09 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>> It isn't obvious to me, however. Suppose I add several JFXPanels into a single Swing top-level window. I may want to show a modal dialog for the first JFXPanel, but leave others operable, for example. This use case seems to be quite valid.
>>>> --
>>>> best regards,
>>>> Anthony
>>>> On 12/21/2012 16:09, Scott Palmer wrote:
>>>>> The whole Swing window must be blocked, if possible.  I don't even understand why this is a question.  If I show a JOptionPane and I give a JPanel as the "parent" component, does it block only the JPanel?  This is no different.  Can you give me an example of when you would only want the JFXPanel blocked?
>>>>> Scott
>>>>> On 2012-12-21, at 4:52 AM, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>>>>>> Hi Scott,
>>>>>> I think that technically this could be implemented.
>>>>>> However, there's a problem: when you create a modal FX dialog specifying a JFXPanel instance as its owner - should the whole Swing window be blocked while the dialog is showing, or should the JFXPanel be disabled only? Why?
>>>>>>  From logical perspective there's not a perfect answer to the above question. No matter what decision we make, some people could get upset.
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>> On 12/21/2012 7:00, Scott Palmer wrote:
>>>>>>> On 2012-12-17, at 5:55 AM, Artem Ananiev <artem.ananiev at oracle.com> wrote:
>>>>>>>> On 12/14/2012 8:19 PM, Werner Lehmann wrote:
>>>>>>>>> Scott,
>>>>>>>>> JFXPanel has quite a few issues (look for JFXPanel or Swing in Jira).
>>>>>>>>> Among those is the filechooser problem. It is probably just one instance
>>>>>>>>> of the problem that a JavaFX stage cannot be modal or on top of Swing
>>>>>>>>> windows.
>>>>>>>> Yes, z-order and modality problems with Swing and FX top-level windows is a known issue. Unfortunately, I don't know a good way to fix it: AWT/Swing doesn't expose enough information to use its windows as owner windows for other UI toolkits.
>>>>>>>> Thanks,
>>>>>>>> Artem
>>>>>>> I responded earlier wondering why the native window handle of the Swing Window wasn't acquired via the publicly available jawt native methods so it could be used as the parent for a Stage or worked into some sort of hierarchy to give a proper parent window to FX Stages and dialogs.   I didn't see any response.  Am I missing something?
>>>>>>> I already do this (get and use the native window handle) in a Swing app so that I can blit live video into my Swing app., a high-end video capture/transcoder/broadcast application. (See http://www.digitalrapids.com/en/Products/StreamZHD.aspx or the one that really could have used FX if it was ready earlier http://www.digitalrapids.com/en/Products/TouchStream.aspx)
>>>>>>> I actually have a need to do the same with a JavaFX app .. but there is no equivalent in FX land for the jawt JNI methods. (I asked for this years ago in the Java FX 1.0 days.)
>>>>>>> Is all of the code involved in JFXPanel->Scene->Window Open Source?  I went poking around but didn't find the implementation of com.sun.javafx.tk.quantum.QuantumToolkit which I think is used to create the peer of the EmbeddedWindow used as the Window for JFXPanels.
>>>>>>> Cheers,
>>>>>>> Scott

More information about the openjfx-dev mailing list