Source code for JavaFX UI controls now available on openjfx

[Kevin Rushforth]

>> , anything like a Canvas2D or a SwingView will
>> need to be done in such a way that the core APIs have no
>> Java2D/Swing/AWT dependencies.
>>     
>
> Yep, I think I mentioned this ;-) What is considered core APIs and what
> is not? Is ui-controls core APIs? (If yes we can stop talking about
> SwingView until we get hands on some non-core API.)
>   

Yes, it is part of the base or core set, which includes the UI Controls, 
Scene Graph, animation, beans & collections & stuff. The main 
requirement is that we need to separate anything that references Java2D, 
etc., into it's own package name space and module.

>> In any case, until more of the platform is open it will be hard to
>> integrate this in a way that won't produce throw-away code, or have to
>> be refactored later.
>>     
>
> Yeah, that's what I was thinking. On the other hand, the throw-away code
> would mostly center around the painting which will need to be improved
> as soon as the platform provides us something better than the
> Image(View) that we use for now. There are lots of other things in the
> SwingView code that will stay (I guess) which is all of the event
> handling, ProxyWindowPeer and glue code.

This might make sense as long as the implementation is something that 
could easily be swapped out later.

> I'd think it'd be worth
> integrating what we have now (if we can, considering the first part of
> the email), maybe in a package name space that is not public, and focus
> on getting out the relevant pieces of remaining code and polishing up
> the things.

And there's the rub. The javafx-ui-controls project cannot directly 
reference Java2D -- at least not in the long term, so it would probably 
be better not to start now, although to be honest, the 
javafx.embed.swing package is currently in the javafx-ui-common module, 
and the universe hasn't exploded as a result. :)  It's just one more 
thing we'd have to move later, but if done carefully (e.g., by putting 
it in a separate non-public package first) it might not be too much trouble.

> (Guys, you want to do an open source project, don't just
> throw out code drops and do NIH fluff... ;-) )
>   

Certainly. We're heading that direction, but as Brian pointed out, it 
will take some time. Also we don't want to add new features too quickly 
at the expense of, say, modularity or platform stability.

Also, in general I would want to be careful putting something in 
javafx-ui-controls just because it's there. If the right place for it is 
something that is currently in the closed source, then that's an 
indicator of something that should probably wait.

Anyway, I don't want to throw a wet blanket on this, since solving this 
problem is worth doing.

-- Kevin