Update on FX plans for JDK 9

[Kevin Rushforth]

Given the recently announced JDK 9 schedule slip [1], we have taken the 
opportunity to explore what RFE's / Features we could possibly now work 
on for inclusion in JDK 9. We wanted to give you a pre-holiday season 
update on what we are currently thinking.


The following RFEs are in progress or planned for JDK 9:

  JDK-8144585: Encapsulate JavaFX impl_* implementation methods
  JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
  JDK-8091308: Define fine-grained permissions for JavaFX
  Expose Hi-DPI properties for render scale and screen scale (FX 
equivalent task for JEP 263 JDK-8055212)
  Multi-resolution image support (FX equivalent task for JEP 251 
JDK-8046010)


Additionally, we have started to look into making public API for some of 
the impl_* API that will otherwise be hidden by JDK-8144585. See 
Jonathan's earlier e-mail on the subject [2]. Here is what we have so far:


  JDK-8144628: Provide API to expose list of showing Windows
  JDK-8144625: Expose code and char properties on KeyCode
  JDK-8144962: Promote TableColumn reorderable property to public API
  JDK-8144871: Add default method getStyleableNode to Styleable interface
  JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl()
  JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and 
Labeled


If there are any we have missed that your application depends on, please 
send e-mail to Jonathan.


Finally, here is an updated list of other RFEs we might consider for JDK 
9. We will not be able to do all of these, but hope to be able to do 
many of them. We could use the help of the OpenJFX community in 
prioritizing this list or possibly adding something that we missed, as 
long as the scope is small enough.


  JDK-8091107: Add java.awt.Desktop support to javafx
  JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX 
(FX equivalent for JEP 272)

  JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
  JDK-8092040: Implement Image writers for JavaFX
  JDK-8091673: Runtime should have a published focus traversal API for 
use in custom controls

  JDK-8089311: [TableCell] commit on focus lost not possible in every case
  JDK-8090477: Customizable visibility timing for Tooltip
  JDK-8092098: [TabPane] Support for draggable tabs
  JDK-8144556: Add support to allow user specified rendering order
  JDK-8145443: [Mac] Render directly to NSWIndow rather than via 
CALayer for non-applet Stage
  JDK-8145154: Provide public API support for PerformanceTracker 
functionality

  JDK-8090763: Public API for Glass's robot functionality

Let us know what is most important to your application.

We will keep you posted with updates on what exactly is being targeted 
(note that you can track it by looking at the Fix Version in JBS, which 
we strive to keep up-to-date).


Thanks!

-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html
[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html

Re: MediaView does not play video on Ubuntu

[Jens Kapitza]

Hi,

are the -extra codecs installed?

http://askubuntu.com/questions/214421/how-to-install-the-mpeg-4-aac-dec
oder-and-the-h-264-decoder


Für Ubuntu 15.10 könnte das hier helfen?!:

sudo apt-get install libavcodec-extra  libavcodec-ffmpeg-extra56  
libav-tools ffmpeg




Am Donnerstag, den 17.12.2015, 11:02 + schrieb Casall, Alexander:
> Hi,

> 
> I’m trying to get the MediaView running on an Ubuntu 14.04
> 
> Target JRE: 1.8.0_66-b17
> I’m building the app on Mac with: jdk1.8.0_40.jdk
> 
> The Video is h264 encoded and is running perfectly on the MacOS.
> 
> When I launch it on Ubuntu the MediaView just shows a blank screen,
> no exceptions, nothing.
> 
> Any suggestions?
> 
> Cheers Alex
> 
> 

Re: Update on FX plans for JDK 9

[Tom Schindl]

[...]

>   JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux

This is a real problem for the SWT-FX integration because SWT is more
and more setting GTK3 as the default. We (the OSGi-FXClassloader)
currently saves people from hard core-dumps by refusing to load FXCanvas
but they'll get a CNF instead with a decent error message why we refused
to load that classes.

Naturally this requires FXCanvas to work in FX9 but that is a different
topic ;-)

Tom

-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Update on FX plans for JDK 9

[Dr. Michael Paus]

Hi,
what I am missing in this list are any activities to generally improve 
the interaction of JavaFX applications
with the operating system they are running on. Some of these issues may 
be covered in an OS specific
way by "JDK-8091517: Implement com.apple.eawt APIs ..." but should 
actually be treated in a more general way.


For example double clicking a file and launching an associated JavaFX 
application. This is a concept
which is used by all major operating systems although the internal 
handling is different. For the Mac

this issue is for example discussed here:

http://stackoverflow.com/questions/29101472/pass-parameters-to-javafx-application-by-double-click-on-file

But as this is a general concept I would also appreciate a general 
solution in JavaFX so that you do not have

to clutter your code with various system specific handlers.

Michael

Am 17.12.15 um 15:21 schrieb Kevin Rushforth:
Given the recently announced JDK 9 schedule slip [1], we have taken 
the opportunity to explore what RFE's / Features we could possibly now 
work on for inclusion in JDK 9. We wanted to give you a pre-holiday 
season update on what we are currently thinking.


The following RFEs are in progress or planned for JDK 9:

  JDK-8144585: Encapsulate JavaFX impl_* implementation methods
  JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
  JDK-8091308: Define fine-grained permissions for JavaFX
  Expose Hi-DPI properties for render scale and screen scale (FX 
equivalent task for JEP 263 JDK-8055212)
  Multi-resolution image support (FX equivalent task for JEP 251 
JDK-8046010)


Additionally, we have started to look into making public API for some 
of the impl_* API that will otherwise be hidden by JDK-8144585. See 
Jonathan's earlier e-mail on the subject [2]. Here is what we have so 
far:


  JDK-8144628: Provide API to expose list of showing Windows
  JDK-8144625: Expose code and char properties on KeyCode
  JDK-8144962: Promote TableColumn reorderable property to public API
  JDK-8144871: Add default method getStyleableNode to Styleable interface
  JDK-8145143: Promote Image.impl_getUrl() to public API as 
Image.getUrl()
  JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and 
Labeled


If there are any we have missed that your application depends on, 
please send e-mail to Jonathan.


Finally, here is an updated list of other RFEs we might consider for 
JDK 9. We will not be able to do all of these, but hope to be able to 
do many of them. We could use the help of the OpenJFX community in 
prioritizing this list or possibly adding something that we missed, as 
long as the scope is small enough.


  JDK-8091107: Add java.awt.Desktop support to javafx
  JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX 
(FX equivalent for JEP 272)

  JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
  JDK-8092040: Implement Image writers for JavaFX
  JDK-8091673: Runtime should have a published focus traversal API for 
use in custom controls
  JDK-8089311: [TableCell] commit on focus lost not possible in every 
case

  JDK-8090477: Customizable visibility timing for Tooltip
  JDK-8092098: [TabPane] Support for draggable tabs
  JDK-8144556: Add support to allow user specified rendering order
  JDK-8145443: [Mac] Render directly to NSWIndow rather than via 
CALayer for non-applet Stage
  JDK-8145154: Provide public API support for PerformanceTracker 
functionality

  JDK-8090763: Public API for Glass's robot functionality

Let us know what is most important to your application.

We will keep you posted with updates on what exactly is being targeted 
(note that you can track it by looking at the Fix Version in JBS, 
which we strive to keep up-to-date).


Thanks!

-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html
[2] 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html

[9] Review request for 8144686 - PathElement.isAbsolute() return value changes after calling absoluteProperty()

[Elina Kleyman Matok]

Chien, Kevin, guys,

Please review my fix for next issue:

 

JIRA: https://bugs.openjdk.java.net/browse/JDK-8144686

WEBREV: http://cr.openjdk.java.net/~ekleyman/8144686_3/

 

Thanks,

Elina

RE: Update on FX plans for JDK 9

[Markus KARG]

Does you plan to make more APIs public the Area class? Applications which
simply want to register events like "when the mouse hovers of this area of a
picture then notify me" where 'area' is an arbitrarily shaped region of the
screen. Currently this has to be done with invisible Shapes, which 'feels'
to be the wrong way as there is an Area class inside of JavaFX. :-)

-Original Message-
From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf Of
Kevin Rushforth
Sent: Donnerstag, 17. Dezember 2015 15:22
To: openjfx-dev@openjdk.java.net
Subject: Update on FX plans for JDK 9

Given the recently announced JDK 9 schedule slip [1], we have taken the
opportunity to explore what RFE's / Features we could possibly now work on
for inclusion in JDK 9. We wanted to give you a pre-holiday season update on
what we are currently thinking.

The following RFEs are in progress or planned for JDK 9:

   JDK-8144585: Encapsulate JavaFX impl_* implementation methods
   JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
   JDK-8091308: Define fine-grained permissions for JavaFX
   Expose Hi-DPI properties for render scale and screen scale (FX equivalent
task for JEP 263 JDK-8055212)
   Multi-resolution image support (FX equivalent task for JEP 251
JDK-8046010)

Additionally, we have started to look into making public API for some of the
impl_* API that will otherwise be hidden by JDK-8144585. See Jonathan's
earlier e-mail on the subject [2]. Here is what we have so far:

   JDK-8144628: Provide API to expose list of showing Windows
   JDK-8144625: Expose code and char properties on KeyCode
   JDK-8144962: Promote TableColumn reorderable property to public API
   JDK-8144871: Add default method getStyleableNode to Styleable interface
   JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl()
   JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and
Labeled

If there are any we have missed that your application depends on, please
send e-mail to Jonathan.

Finally, here is an updated list of other RFEs we might consider for JDK 9.
We will not be able to do all of these, but hope to be able to do many of
them. We could use the help of the OpenJFX community in prioritizing this
list or possibly adding something that we missed, as long as the scope is
small enough.

   JDK-8091107: Add java.awt.Desktop support to javafx
   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX
equivalent for JEP 272)
   JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
   JDK-8092040: Implement Image writers for JavaFX
   JDK-8091673: Runtime should have a published focus traversal API for use
in custom controls
   JDK-8089311: [TableCell] commit on focus lost not possible in every case
   JDK-8090477: Customizable visibility timing for Tooltip
   JDK-8092098: [TabPane] Support for draggable tabs
   JDK-8144556: Add support to allow user specified rendering order
   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
for non-applet Stage
   JDK-8145154: Provide public API support for PerformanceTracker
functionality
   JDK-8090763: Public API for Glass's robot functionality

Let us know what is most important to your application.

We will keep you posted with updates on what exactly is being targeted (note
that you can track it by looking at the Fix Version in JBS, which we strive
to keep up-to-date).

Thanks!

-- Kevin

[1]
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html
[2]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html

Re: Update on FX plans for JDK 9

[Tom Schindl]

Hi,

I have a another API I'd like to get into FX9 which makes my
implementation of Source-Code editors smoother:

https://bugs.openjdk.java.net/browse/JDK-8090688

It even has a patch which most likely does not apply any more because of
the whole stuff getting public API but I would recreate it if it gets on
the FX9 list.

Tom

On 17.12.15 15:21, Kevin Rushforth wrote:
> Given the recently announced JDK 9 schedule slip [1], we have taken the
> opportunity to explore what RFE's / Features we could possibly now work
> on for inclusion in JDK 9. We wanted to give you a pre-holiday season
> update on what we are currently thinking.
> 
> The following RFEs are in progress or planned for JDK 9:
> 
>   JDK-8144585: Encapsulate JavaFX impl_* implementation methods
>   JDK-8143158: [Text, TextFlow] Make public API from internal "impl" APIs
>   JDK-8091308: Define fine-grained permissions for JavaFX
>   Expose Hi-DPI properties for render scale and screen scale (FX
> equivalent task for JEP 263 JDK-8055212)
>   Multi-resolution image support (FX equivalent task for JEP 251
> JDK-8046010)
> 
> Additionally, we have started to look into making public API for some of
> the impl_* API that will otherwise be hidden by JDK-8144585. See
> Jonathan's earlier e-mail on the subject [2]. Here is what we have so far:
> 
>   JDK-8144628: Provide API to expose list of showing Windows
>   JDK-8144625: Expose code and char properties on KeyCode
>   JDK-8144962: Promote TableColumn reorderable property to public API
>   JDK-8144871: Add default method getStyleableNode to Styleable interface
>   JDK-8145143: Promote Image.impl_getUrl() to public API as Image.getUrl()
>   JDK-8144956: Remove impl_cssGet*InitialValue() methods from Node and
> Labeled
> 
> If there are any we have missed that your application depends on, please
> send e-mail to Jonathan.
> 
> Finally, here is an updated list of other RFEs we might consider for JDK
> 9. We will not be able to do all of these, but hope to be able to do
> many of them. We could use the help of the OpenJFX community in
> prioritizing this list or possibly adding something that we missed, as
> long as the scope is small enough.
> 
>   JDK-8091107: Add java.awt.Desktop support to javafx
>   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX
> (FX equivalent for JEP 272)
>   JDK-8087516: Conditional support in JavaFX for GTK 3 on Linux
>   JDK-8092040: Implement Image writers for JavaFX
>   JDK-8091673: Runtime should have a published focus traversal API for
> use in custom controls
>   JDK-8089311: [TableCell] commit on focus lost not possible in every case
>   JDK-8090477: Customizable visibility timing for Tooltip
>   JDK-8092098: [TabPane] Support for draggable tabs
>   JDK-8144556: Add support to allow user specified rendering order
>   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> for non-applet Stage
>   JDK-8145154: Provide public API support for PerformanceTracker
> functionality
>   JDK-8090763: Public API for Glass's robot functionality
> 
> Let us know what is most important to your application.
> 
> We will keep you posted with updates on what exactly is being targeted
> (note that you can track it by looking at the Fix Version in JBS, which
> we strive to keep up-to-date).
> 
> Thanks!
> 
> -- Kevin
> 
> [1]
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003237.html
> [2]
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-December/018338.html
> 
> 


-- 
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Update on FX plans for JDK 9

[Mike Hearn]

>
>   JDK-8091107: Add java.awt.Desktop support to javafx
>   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX (FX
> equivalent for JEP 272)
>

Exposing platform APIs is a big deal for anyone who wants to make an app
that really benefits from being on the desktop. Doing things like handling
files, registering URL handlers etc was a big PITA in my app. Definitely +1
to supporting these cases better.


>   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> for non-applet Stage
>

It's unclear from this description or the bug what the benefit of doing
that would be. Performance?


>   JDK-8145154: Provide public API support for PerformanceTracker
> functionality
>   JDK-8090763: Public API for Glass's robot functionality
>

For testing and so on, public APIs seem lower priority to me. A developer
can always override Jigsaw from the command line and use whatever internal
APIs are needed. Breakage is less of a concern because it's under the
control of the developer.

The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a
slick auto update system. Shipping apps that can't update themselves in
2015 is unacceptable even for corporate deployments.

[9] Review Request: 8145602: [macosx] Remove QTKit based media player

[David DeHaven]

Kevin, Alexander, please review the changes to remove QTKMediaPlayer and do 
some cleanup in the AVF media player since we no longer build against the 10.7 
SDK.

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

webrev:
http://cr.openjdk.java.net/~ddehaven/8145602/rt/v0/

Note that this is blocked by JDK-8145604, so this won't be pushed until Kevin 
finishes that.

Also note that I've de-tabbed a few files, so the formatting looks off in the 
webrev (something is expanding the tabs to 8 spaces instead of 4). It looks 
correct in the code, if in doubt you can apply the patch and check it. 
AVFKernelProcessor.cpp and AVFMediaPlayer.mm appear to be unchanged because 
it's whitespace only (de-tabbed) and webrev was set to ignore those changes.

-DrD-

MediaView does not play video on Ubuntu

[Casall, Alexander]

Hi,

I’m trying to get the MediaView running on an Ubuntu 14.04

Target JRE: 1.8.0_66-b17
I’m building the app on Mac with: jdk1.8.0_40.jdk

The Video is h264 encoded and is running perfectly on the MacOS.

When I launch it on Ubuntu the MediaView just shows a blank screen, no 
exceptions, nothing.

Any suggestions?

Cheers Alex

[9] Review Request: 8143598: Stage min/max Width values not scaled for DPI

[Jim Graham]

Jira: https://bugs.openjdk.java.net/browse/JDK-8143598
webrev: http://cr.openjdk.java.net/~flar/JDK-8143598/webrev.00/

Since the min/max properties are enforced asynchronously (at least on 
the Windows platform), there wasn't an easy test case to write to verify 
that the values were enforced unfortunately.


This will be back-ported to 8u-dev shortly...

...jim

Re: Update on FX plans for JDK 9

[Benjamin Gudehus]

>For testing and so on, public APIs seem lower priority to me. A developer
can always override Jigsaw from the command line and use whatever internal
APIs are needed.

That's true, although is increases the initial hurdle of testing a bit.

>JDK-8145154: Provide public API support for PerformanceTracker
functionality

The ability to register custom Loggers would be nice; they currently behind
private fields.



On Thu, Dec 17, 2015 at 11:05 PM, Mike Hearn  wrote:

> >
> >   JDK-8091107: Add java.awt.Desktop support to javafx
> >   JDK-8091517: Implement com.apple.eawt APIs that make sense in JavaFX
> (FX
> > equivalent for JEP 272)
> >
>
> Exposing platform APIs is a big deal for anyone who wants to make an app
> that really benefits from being on the desktop. Doing things like handling
> files, registering URL handlers etc was a big PITA in my app. Definitely +1
> to supporting these cases better.
>
>
> >   JDK-8145443: [Mac] Render directly to NSWIndow rather than via CALayer
> > for non-applet Stage
> >
>
> It's unclear from this description or the bug what the benefit of doing
> that would be. Performance?
>
>
> >   JDK-8145154: Provide public API support for PerformanceTracker
> > functionality
> >   JDK-8090763: Public API for Glass's robot functionality
> >
>
> For testing and so on, public APIs seem lower priority to me. A developer
> can always override Jigsaw from the command line and use whatever internal
> APIs are needed. Breakage is less of a concern because it's under the
> control of the developer.
>
> The biggest lack in the JavaFX/javapackager/jlink story is still, by far, a
> slick auto update system. Shipping apps that can't update themselves in
> 2015 is unacceptable even for corporate deployments.
>