Swing in JavaFX demo

In the last days, I fixed some focus issues and improved painting for the SwingView and today put together a little demo that shows a JavaFX TabPane, with part of the famous SwingSet2 demo in one tab and a little JavaFX demo in the other. You will notice that the SwingView is a little slow, that’s because of the way we paint Swing components into JavaFX scene, which is very far from optimal. More to that in a later post. For now, enjoy the demo.

Swing in JavaFX demo

HyperTree renderer for JavaFX

Today I kindof went back to the beginning of my free software ‘career’ and implemented a hyperbolic tree renderer for JavaFX:

HyperTree renderer for JavaFX

This has been the thing that brought me to GNU Classpath, back then I made GNU Classpath able to render this in Swing/Java2D

This component is slightly improved, it can renderer arbitrary tree structures and instead of displaying colorful rectangles, it can basically display any shape, control, image or whatever you can come up with as JavaFX node.

This will be included in ThingsFX shortly. I will also make a live demo of this, because a screenshot doesn’t really convey how cool the component is (dragging the tree around with the mouse pointer is sooo much fun 😀 ).

Update: Here’s the live demo.

Update: Here’s the source code.

Key event support in ThingsFX Swing/JavaFX integration

It has been quite a challenge to get the focus and key event supported in the SwingView component, but it finally works. i.e. you can now give focus to Swing components inside a JavaFX SwingView and type stuff into it:

Key event support in SwingView

 

JFreeChart in JavaFX demo

Last night Mario and me put together a demo of JFreeChart running inside JavaFX, as a Swing panel, using the Swing-JavaFX integration that we implemented for ThingsFX. I packaged this demo as a webstart applet/application for you to try out live. This should work at least on Windows. Unfortunately not on Linux since JavaFX has not yet been released for Linux (Go, Oracle, Go!) and I haven’t tried on MacOS. If the demo doesn’t work for you, you can still watch the screencast that Mario did below. Notice that this is not JFreeChart rendered to an image and added as ImageView, it’s a live Swing panel added inside JavaFX (I am sure there could be more impressive demos showing animations in the charts or such… material for another post I guess 😉 ). The source code for the demo can be found here.

Cacio Testing Howto

Now that Cacio Testing is in a fairly usable shape, I thought it might be useful to write up some instructions how to get going with it, in case you want to test it.

You will need: Mercurial, Maven and JDK7

First clone the source code to your computer:

hg clone hg.openjdk.java.net/caciocavallo/ng/ cacio

Then build it using maven:

cd cacio
mvn clean install

Then in your project where you intend to use it, add this to the Maven dependencies:

    <dependency>
      <groupId>net.java.openjdk.cacio</groupId>
      <artifactId>cacio-tta</artifactId>
      <version>1.0-SNAPSHOT</version>
      <scope>test</scope>
    </dependency>

Finally, annotate your testcase with:

@RunWith(CacioTestRunner.class)
public class SimpleFESTTest {
...
}

Or if you used FEST’s GUITestRunner, you might want to use the equivalent:

@RunWith(CacioFESTRunner.class)
public class SimpleFESTTest {
...
}

Those steps should get you running with Cacio Testing. When you run a test with the above annotation, it should no more popup any windows or steal focus. I’d be happy if you could give it a try and report back how it goes, especially in case of problems.

Keyboard mapping support for Cacio Testing

Yesterday I hacked a little on our solution for reliable user interface testing, Cacio Test. It is an AWT/Swing toolkit implementation that renders into an offscreen buffer, thus avoiding any interaction with the computer’s desktop. Event support is driven exclusively by java.awt.Robot. One of the problems is that the Robot is very low level. Simulated keyboard input is implemented by keyPress() and keyRelease(), which take a keyCode. A key code denotes a key on a keyboard like ‘A’, ‘SHIFT’ or ‘ENTER’ and is expressed by the varios KeyEvent.VK_* constants. However, there is also a notion of higher level character input in the form of KeyEvent.KEY_TYPED events. Such events express that a character has been input, not a specific key. Often, a keyChar needs several keys to be pressed together or in sequence. This is highly locale specific. (I realized that Java has no way to determine the keyboard mapping locale. For example, my computer runs under DE but has a US keyboard. Any ideas?) For example, the @ char is typed by pressing SHIFT+2 on a US keyboard, but by AltGr+Q on a german keyboard. Yesterday evening I implemented full key -> char mappings for US and DE locales. With this change, Cacio Testing can now be used to test keyboard input interactions:

ThingsFX launched

Last weekend, Robert Lang Branchat launched thingsfx.com. Together with Mario and my own nothingness, we want to build up an open source repository of amazing and useful extensions to JavaFX, like additional controls, animations, layouts, etc etc. Currently we are working on embedding Swing inside JavaFX scene. We also have some other extraordinary cool things in the pipeline and many many ideas for the future. Let’s roll! Watch out on this blog and here and here for more news.

CacioWeb – The Java Deployment Solution of the future

In this post, I would like to give an overview of what CacioWeb is, what we plan to do with it in the near future, and how you can participate.

What is it now?

CacioWeb is way to deploy Java Swing applications on a server, which allows it to ‘run’ on many clients. Infact, it actually runs on the server, but only does drawing, event handling, windowing, etc on the client. On the client side, it only requires a HTML5 capable browser (it goes in turbo mode on websocket enabled browsers). The solution is somewhat comparable to a VNC based solution, but at the same time different in some ways. Most importantly, it hooks directly into the graphics stack of Java. Drawing and windowing commands are sent directly from the Java graphics stack to the client’s JavaScript engine. Java applications deployed using CacioWeb run on a wide variety of systems, including such systems that don’t have (or can’t have) Java or a suitable plugin installed, like Android phones and Apple products. Deploy Once – Run Anywhere. This core engine is open source and part of the Caciocavallo project, which is an OpenJDK project to enable easy porting of Java’s graphics stack to new and exciting platforms. It has been implemented by the famous Clemens Eisserer as a Google Summer of Code project. Find a running demo here. (If it’s down, it has probably been DOSed, the server is really not very powerful, being a shared server.)

What are we planning for the future?

There are several features that we plan to implement and offer as a commercial product through LadyBug:

  • Most importantly, we are implementing a web frontend for easy deployment and configuration of Java Swing applications to the CacioWeb nodes. This could be accomplished simply by uploading an executable JAR file containing the application to the server. This management service should also offer a way for automated deployments using common build tools like Ant or Maven.
  • Another great feature we have in mind is a clustering service. It would be possible to host many CacioWeb nodes on each server, or even host several servers with several nodes each. The clustering service would distribute incoming sessions according to configurable rules. This will have significant advantages 1. load can be balanced across several nodes. 2. if one nodes goes down, sessions would be directed to other available nodes, thus increasing failover. 3. if you configure one session per node, you achieve maximum stability, if one user crashes one JVM, it will not take down other users. 4. If necessary, new nodes can easily be added by registering in the node manager. In short, this will greatly extend stability and scalability of CacioWeb.
  • We will provide access to the client’s filesystem using standard Java APIs. Normally, when the application is running on the server, using java.io.File would naturally access the server’s filesystem (which would be restricted by a SecurityManager anyway). We would like to redirect this to the client filesystem. This would most likely access a sandboxed directory on the client only, up to whatever the client JavaScript implementation provides us.
  • We are working to provide client side printing support using the standard Java printing APIs.
  • Last but not least, the whole CacioWeb application will ship as a standard .ear file, ready to be deployed on any J2EE compatible server.

How do we get there?

The above features are currently not yet implemented. We are currently working on implementing the features, but currently don’t have the funding to do so in a timely manner. In LadyBug, we decided to not go after venture capital. Instead, we would like to try out some guerilla tactics to get going. The idea is this: If you (as a company or invididual) think a solution like outlined above would be a great thing to have, and would be interested in purchasing a license for, please contact us and tell us what would be your intended usage scenario. We would basically offer to buy a share of the development of such a product. Based on the feedback, i.e. number of interested parties, we would find out a price for such a share, and if we end up at a reasonable price and get enough support, we would start work on it. In return for the support, we would of course provide a license for the product once it’s done, within a timeframe of maximum 6 months, plus the chance to directly participate in the actual development, e.g. you could provide us the application that you intend to run for testing, etc. Please let us know what you think.