Draggable tabs

[Mike Swingler]

I agree there is a role for a JAWT-like API, but the onus should be completely on the developer to query the native platform aperture handle for capabilities (where "none" is a perfectly valid answer).

The mechanics of who triggers update events, what kind of context you draw on (or attach to!), who gets/sends resize notifications, and how event dispatch works are all completely different between platforms, and even from context to context on the same platform. Ideally, things like event dispatch should go through as few layers of translation as possible (to enable things like chinese character drawing on trackpads, etc)...but things like out-of-process applets will prevent you from ever having the raw events, because they go through NPAPI. As NPAPI has taught us, echoing the platform native events is a fools errand since those events can expand infinitely in very platform-specific ways.

Hence, the developer needs to query for capabilities, and the platform developer should feel free to spawn as many variations and capabilities as they find themselves sitting on top of from the native platform vendor. Developers can tap into as much raw power of the underlying platform as they can handle, at the cost of sitting on top of the ever-shifting native platform.

Regards,
Mike Swingler
Apple Inc.

On Mar 19, 2012, at 7:49 AM, steve.x.northover at oracle.com wrote:

> Hi all,
> 
> What this means is that JFX will never interoperate with any arbitrary native operating system technology.  That's bad.
> 
> I understand both sides:  First off, application programmers just want to get the job done.  If getting the job done requires integrating native calls into JFX, then they need to get hold of the underlying operating system resources to feed the native calls.  On the other hand, the underlying operating system resources that FX relies on are different between the different platforms and have security implications.
> 
> Right now, if you want to integrate native technologies and FX, you can embed FX in Swing or SWT and make all the native calls you want from Swing or SWT.  I realize that this is not a great solution.  A better solution is to make the resources available in a controlled fashion.
> 
> Thoughts?
> Steve
> 
> On 19/03/2012 3:13 AM, Artem Ananiev wrote:
>> 
>> On 3/17/2012 5:20 PM, Kevin Rushforth wrote:
>>> 
>>> Jonathan Giles wrote:
>>>> 
>>>> On 16/03/2012 5:25 a.m., martin at percossi.com wrote:
>>>> 
>>>>> Second question (speculative): Is it possible to get a "raw" window
>>>>> handle (i.e. in Microsoft Windows)? Basically, if you're writing a
>>>>> VST plugin host, you need to provide a parent window handle within
>>>>> which the VST plugin can stuff its GUI. In the worst case, this would
>>>>> create an entirely new window, but ideally, I would be able to get a
>>>>> raw window handle and "place" the GUI into some part of the JavaFX
>>>>> GUI. Am I asking for too much? ;)
>>>> I'll leave this to the glass team to answer.
>>> 
>>> I'm not the glass team, but I doubt very much we would ever want to
>>> expose this via public API. In addition to security concerns, it would
>>> expose too much of the implementation, and would be very difficult to do
>>> in a way that was robust and didn't tie our hands for future evolution.
>> 
>> Completely agree here. Note that there may be no "raw" window handle behind JFX scene/stage at all, for example when it's embedded in JFXPanel or runs as applet on Mac OS X.
>> 
>> Thanks,
>> 
>> Artem
>> 
>>> -- Kevin