Re: Camera Access
On Aug 5, 2015, at 5:06 PM, Jens Kapitza j.kapi...@schwarze-allianz.de wrote: Am Dienstag, 4. August 2015, 13:26:06 schrieb Scott Palmer: The issue is: https://bugs.openjdk.java.net/browse/JDK-8090438 https://bugs.openjdk.java.net/browse/JDK-8090438 A target release has not been set. But I really hope it could make it into 9.0. Has there been any further discussion on this? Why not like this? https://github.com/sarxos/webcam-capture/tree/master/webcam-capture-examples/webcam-capture-javafx When I ran the JavaFX example on OS X, it locked up before even showing a UI. (It may have something to do with accessing Swing/AWT classes off the Event Dispatch thread, or before such thread exists*.) It’s also a pretty heavy library with way too many dependencies. It cobbles together or relies on 10 different APIs/libraries, or “drivers to get the job done. In short it’s a mess compared to what the camera API should be. For reasonable camera access Java needs something much simpler. Cameras are built-in to most of the devices Java runs on, and have been for some time. Heck, even the Raspberry PI has a standard camera module and it runs JavaFX. There should be an official API for camera access. *On a side note, it’s a shame that there is no Image data type that is independent of JavaFX/Swing so manipulating image data doesn’t have to bring in a particular UI toolkit, and therefore force use of Swing even though your API is JavaFX based. E.g. ImageIO requires Swing-based images when it should have been independent of the UI toolkit. A Raster interface could be factored out and shared between whatever UI image classes are used, ImageIO, and the future camera API… probably too late now though. Regards, Scott
Re: Results of review of private JavaFX API for consideration to make public in JDK 9
Hi Jonathan, thanks for the summary! pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API I'd like to help with the public API for profiling and performance tracking (mainly PulseLogger, maybe PerformanceTracker). These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class Sounds good. TestFX has a dependency to com.sun.javafx.application.ParametersImpl to provide the ability to test multiple different `Application`s. It currently depends on private fields and methods of internal classes. Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. The headless testing feature in TestFX has dependencies to com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the AWT robot, the normal testing mode needs no access to the internal APIs. The screenshot feature in headless testing depends on com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. Additionally we also need access to com.sun.glass.ui.PlatformFactory in order to activate Monocle on desktop systems. --Benjamin On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles jonathan.gi...@oracle.com wrote: Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: == 'Toolkit' API == A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. == 'Traversal' API == This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. == 'Collections Event' API == There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. == 'Utils' API == There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class (although there are no plans to move all the methods over!). == Miscellaneous API == Finally, there are a few classes that popped up quite frequently. Here is the list, and my thoughts on what to do with them: 1) com.sun.javafx.runtime.VersionInfo:
Re: Results of review of private JavaFX API for consideration to make public in JDK 9
If there were to be an API for getting basic graphics device data, what would that look like and would it be hard to write? My app uses some internal APIs not listed above to query the pixel scale and whether we're using software/hardware graphics, to reduce usage of some expensive effects. These are just booleans, essentially. On Fri, Aug 7, 2015 at 11:51 AM, Benjamin Gudehus hasteb...@gmail.com wrote: Hi Jonathan, thanks for the summary! pull up your sleeves and work with us to get the API into a shape where it is good enough to commit to as public API I'd like to help with the public API for profiling and performance tracking (mainly PulseLogger, maybe PerformanceTracker). These classes are com.sun.javafx.util.Utils, com.sun.javafx.PlatformUtil, and com.sun.javafx.application.PlatformImpl. As most of these classes are just a collection of self-contained methods, it is quite likely that a number of these methods will find public API alternatives in a new class Sounds good. TestFX has a dependency to com.sun.javafx.application.ParametersImpl to provide the ability to test multiple different `Application`s. It currently depends on private fields and methods of internal classes. Robot: A good API to make public, but not a small API, so the scope is possibly too great for JDK 9. The headless testing feature in TestFX has dependencies to com.sun.javafx.robot.FXRobot and com.sun.glass.ui.Robot. As TestFX uses the AWT robot, the normal testing mode needs no access to the internal APIs. The screenshot feature in headless testing depends on com.sun.javafx.robot.FXRobotImage and com.sun.glass.ui.Pixels. Additionally we also need access to com.sun.glass.ui.PlatformFactory in order to activate Monocle on desktop systems. --Benjamin On Fri, Aug 7, 2015 at 1:10 AM, Jonathan Giles jonathan.gi...@oracle.com wrote: Hi all. In April of this year a discussion began when news broke that with JDK 9 access to private com.sun.* APIs would be disappearing [1]. A while back I posted a request to openjfx-dev for people to send me their JDeps output so that it could be analysed and used to inform our decisions around which API we should try to promote into public API. The response was very useful (and I should note: its too late now, please don't send me anymore JDeps files), and I believe we have the beginnings of a plan on how to move forward. Before I outline the plan, please note that this discussion would ideally _not_ devolve into a feature requests discussion. What we are wanting to talk about today is simply API that exists in the com.sun.* package namespace which we can conceivably bring out of this namespace for JDK 9. Developing new API is expressly out of scope (unless it is related to simplifying or wrapping the com.sun.* API). Another important point - UI control skins and a lot of very useful CSS API are being made public under JEP 253 [2]. A lot of the skin code has already been cleaned up, simplified, documented, etc, and will be merging into a repo very soon. I'll also post a separate post about JEP 253 soon. So, what does my JDeps analysis show (ignoring UI Controls and CSS usage, which has been largely resolved by JEP 253)? I can sum it up in the following categories: == 'Toolkit' API == A lot of people use a small amount of API from Toolkit, such as the API for nested event loops, to fire a pulse, and to add / remove pulse listeners. Based on this analysis, the current thinking is to add API into the javafx.application.Platform class to enable the first two use cases above (nested event loops and pulse firing). The third use case needs more engineering effort, and is a far less common use case, so isn't being considered for JDK 9. == 'Traversal' API == This API lives in com.sun.javafx.scene.traversal, and is quite useful when writing custom controls to ensure that keyboard traversal puts the focus in the right node at the right time. My ControlsFX open source project is a common (ab)user of this API, so I have a vested interest in making this public. Having said this, the API is actually in quite good shape, and it is possible with just a little JavaDoc work it could make the move into javafx.scene.traversal. == 'Collections Event' API == There exists classes in com.sun.javafx.collections that are quite useful if you create your own custom ObservableList implementation and want to fire events at certain times. In my analysis there are only two projects using these APIs: ControlsFX and JVx by SIB Visions. The other pertinent point is that this code is quite easy to reproduce, so, whilst I would like to see this API public, it doesn't seem to make sense for JavaFX 9. == 'Utils' API == There exists three classes that are quite commonly used by people for the various utility methods contained within. These classes are com.sun.javafx.util.Utils,
JavaFX Self-contained PKG and MacAppStore_PKG did not work
Hi, I used JavaFX ant tasks to create all native packages on Mac OS X (JDK 8u51 on latest Mac OS X). Both .app and .dmg packages are working flawlessly. However, for PKG package, the very first installation was successful and my application show up in /Applications folder. However, if I delete my app from /Applications and use PKG package to install again, the installation process will always run successfully. However, my application did not show up inside of /Applications. I already tried to use pkgutil —forget application id and rebooted my Mac. It is still the same result. Installation of PKG package are always successful. But my application is not installed under /Applications folder. Thanks, Tai
