Sorry everyone we got hacked and it will take us a little while to put the site back together. Please be patient with us.
More days. Much work. Such links. Wow.
- Johan Vos continues to keep busily improving the JavaFX Android support. This week he has a very interesting blog post about using Android APIs from within JavaFX, such as the location services.
- Laurent Nicolas has posted part three about custom controls in JavaFX.
- Robert Ladstätter has posted about JavaFX 3D and LeapMotion.
- Michael Hoffer has posted video and code demonstrating how to get a ‘milk glass’ effect with JavaFX. Quite an interesting approach making use of the JavaFX snapshot API.
- The ‘cathive developers‘ have open sourced fx-cdi: “some useful classes that help you to use CDI alongside / within your JavaFX applications.”
- Sébastien Bordes has posted about a trick he learned from Jens Deters about cutting down on the amount of code required to load fxml files, simply by creating a convention where the fxml file is named in relation to the class file that will load it.
- Falko Riemenschneider has posted about an interactive JavaFX GUI development tool he has written that uses a custom DSL, rather than Java, to specify the user interface.
- The ustesis blog has a video (but no code that I can see?) showing a combined LineChart and TableView user interface, where they both visualise the same data.
- Jeff Martin has posted an update to SnapCode, the free educational IDE for Java and JavaFX, including a video of animation programming and pen graphics programming.
Catch you all again next week! 🙂
Here we go all over again! Enjoy! 🙂
- The most important thing for everyone this week is to go and fill in the JavaFX for tablet / mobile / embedded survey. We need your feedback, so please fill it in if you haven’t already, even if you don’t care about JavaFX on these platforms. Thanks! 🙂
- Richard Bair kicked off a fx-games project over on bitbucket for the OpenJFX community to work together on a game to test out the graphical power of JavaFX. The first game being worked on is a JavaFX version of the classic tower defense. Join in on the discussions and offer to start coding or providing graphics resources!
- Florian Brunner has stepped into the JavaFX rich client platform arena with his own submission called Drombler FX, which at first glance looks like it strikes a really nice balance (and does some things the way I would do them if I could, e.g. annotations for actions) 🙂
- Gerrit Grunwald updated his post from last week to mention he has updated his library to support converting text into SVG paths.
- Daniel Zwolenski has a post titled ‘JavaFX with a SpringMVC REST server in 5 minutes‘, which talks about his new Maven archetype for quickly creating REST+JavaFX projects.
- jaxenter did a nice post on the recently released DataFX 1.0.
- Arnaud Nouard did a teaser post about his work on a SwingNode API to allow for integrating Swing inside JavaFX.
- Thierry Wasyl has two posts this week. Firstly he has a post about building JavaFX runnable JAR with IntelliJ IDEA (and Ant). Secondly he has a post about the JavaFX TableView control, in particular allowing to size the column width using percentages (there is actually a Jira issue (RT-17180) for this feature request, so it would be ideal to see this contributed back to OpenJFX).
- Speaking of TableView, Amrullah has posted a blog post about their work on the JavaFX TableView control to add in a bunch of new functionality. Again, there may be stuff in here that could be contributed back to OpenJFX.
- Leon Atherton has blogged about handling threads and concurrency in JavaFX applications.
- Sri kalyan has blogged about some JavaFX event handling tips.
- Laurent Nicolas has updated his radial menu control to support submenus and other features.
- Randahl Fink Isaksen has posted his thoughts on designing for multiple screen resolutions in JavaFX.
Catch you next week.
I am presently typing away on a new Retina Display MacBook Pro, and it is an interesting experience. The visual clarity is stunning. It is akin to the feeling of going from Atari to Nintendo, or Nintendo to Nintendo 64, or standard def to Hi-Def. I just didn’t realize what kind of poor quality I was looking at before.
But it isn’t all rainbows and sunshine. All of Apple’s applications look stunning. But many 3rd party apps look bad (including Java apps), and web browsing is horrific. The problem is high-DPI, and how Apple went about solving the HDPI problem.
On Retina MacBook Pro displays, there are some 220 pixels per inch. If you rendered everything 1-to-1 on such a display, the text (and everything else) would look tiny. You’d need a bionic eye (or a magnifying glass) to read anything on the screen. Or at least, really young eyes. So instead, everything needs to be scaled up.
For vector graphics and text, this is pretty straightforward. You just scale things up and render at the higher resolution and things look great. But for images it isn’t so simply. Scaling images produces a blurry result. And that, in fact, is the experience of using a retina display when browsing websites. You will come to some websites where the text is crisp and the images are all blurry. Other websites have some crisp text and some blurry text, ostensibly either because intentionally or unintentionally the web site is rendering text to an image and then the image is being scaled. And it makes for a horrendous user experience.
In Apple’s applications (starting with the iPhone and iPad with their retina displays), the solution to the problem is for the application developer to supply two images instead of one for each image asset. For example, the splash screen will be supplied with two images, one at normal resolution and one at 2x the resolution. The files are named the same but the 2x one is named according to some convention, such that at runtime the platform will lookup the 2x version on retina behind the scenes. In such a way, your application says “fooImage.png” but “fooImage@2x.png” is looked up instead when on a machine with a retina display.
At the moment, all Java applications (including FX) are pixel-doubled, such that everything (text, images — everything) are doubled and look blurry. But since I’m going to be working on a retina MacBook for the next several years, we’ve got to fix this situation. Driving me UP THE WALL. Our plan is to follow Apple’s lead, and automatically attempt to load the @2x image if one is available, and to otherwise signal to Mac OS X that we’re a high-DPI aware application and it shouldn’t pixel double everything on us.
One thing to be aware of here is that Canvas and ImageWriter are not going to be able to deal with high-DPI right off the bat. Your application is written as if it is on a normal display, but Canvas ends up needing to be pixel doubled. In the future we’ll add API so you can detect this situation and draw into a larger canvas (or automatically scale everything up for you).
I can’t wait for FX to be in hi-res!
After a ton of work and navigating the legal bureaucracy, Scott Kovatch on the JavaFX team has successfully put the first JavaFX Application (that we know of) into the Mac App store! It was particularly fun to read James Gosling’s ringing endorsement. As most of you probably know, Ensemble is our sampler application which has all the Javadoc and a hundred or so samples of everything from animations to controls to binding to 3D. It is also the application we will continue to build up as we go along. We originally released it with JavaFX 2.0, and the team has been adding content to it ever since (thanks Debbie! thanks Prague! thanks team!).
Getting it into the Mac App Store is a big deal. We first added support to produce native app bundles earlier this year, such that any JavaFX application can be co-bundled with the JRE to create a platform specific app bundle — a MacOS X .app and .dmg, for example, or an .msi and .exe for windows, or .deb / .rpm on linux. These app bundles are inherently secure (since they don’t rely on remote code execution, unlike Applets and WebStart). They also are completely “normal” for the end user. And they’re the only way to get apps into an App store. Oh, and since Java is co-bundled, these app bundles do not require Java to be preinstalled — so no more headaches dealing with what version of Java is installed and redirecting to install a specific version of Java. It all just works.
So go ahead. Build your desktop applications with JavaFX, and deploy to the Mac app store. You’ll be glad you did 😉
I was inspired by Dean Iverson’s tweet with a audio equalizer in JavaFX:
#JavaFX rocks. Literally. An example from our upcoming Pro JavaFX 2 book: pic.twitter.com/tSI4Vry4
and the equalizer view from that Pro JavaFX 2 example app: pic.twitter.com/T6jxvrf9
. updated pic.twitter.com/FqzgVimG
So wanted to have a go at doing one my self, so little while later I have a design and built a working application. Demo video after the break.