Sorry for the delayed post this week, I’ve been a little bogged down in other work recently. But anywho, here we go for another week – enjoy!

JavaFX

• Richard Bair was busy this week, putting up three blog posts here at FX Experience. The first post talks about his investigation into restricting input on a TextField control. This then leads on to a MoneyField control that he has made available, and finally a blog post about how he slightly simplified the MoneyField by adding more DefaultProperty annotations to UI control properties.
• Phil Race has blogged about the LCD text support in JavaFX 2.1.
• Michael Heinrichs has blogged about creating read-only properties in JavaFX.
• Thom Schindl announced the release of e(fx)clipse 0.0.12.
• Daniel Zwolenski has published an article on OTN titled “Building Java EE Applications in JavaFX 2.0“.
• Adam Bien has blogged about setting the JavaFX 2.0 runtime at startup (and solving “Unable to read ../rt/” problem).
• Jim Weaver put up a number of quotes from developers with their reactions to the recent release of the developer preview of JavaFX 2.1 for Linux.
• For those in the St Louis area, Weiqi Gao is giving another JavaFX 2.0 talk covering the core concepts.
• Speaking of Weiqi, he has also blogged about how to get started running JavaFX 2.1 on a 64-bit Ubuntu install.
• Mark Anro Silva has created a 3D neon globe which can be started via webstart (although I can’t see the source code).
• Dustin Marx has blogged about creating a JavaFX application that can solve quadratic equations.
• William Antonio has blogged about a JavaFX application that he has created that consumes the GateIn navigation REST API.
• Altuğ Uzunali has created a waterfall display (aka a spectrogram).

Swing

• SwingX 1.6.3 was released this week.

That’s all for another week. Catch you again in a weeks time.

While writing the last blog post on segmented buttons, I found a bug (or rather, a feature missing from ToolBar). I had to use the following FXML:

<?xml version="1.0" encoding="UTF-8"?>

<?import java.lang.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>

<BorderPane id="background" prefWidth="800.0" prefHeight="600.0" xmlns:fx="http://javafx.com/fxml">
    <top>
        <ToolBar>
            <items>
                <Region styleClass="spacer" />
                <HBox styleClass="segmented-button-bar">
                    <Button text="Tasks" styleClass="first" />
                    <Button text="Administrator" />
                    <Button text="Search" />
                    <Button text="Line" />
                    <Button text="Process" styleClass="last" />
                </HBox>
            </items>
        </ToolBar>
    </top>
</BorderPane>

You will notice that the ToolBar required the <items> element for adding the, well, items to the ToolBar. This extra level of verbosity was just asking to be smashed. I filed & fixed & Greg reviewed the fix for RT-19476. As of a few minutes ago, this fix has gone into the control’s scrum forest and should be making its way into the next weekly build. So now, you can just say:

<?xml version="1.0" encoding="UTF-8"?>

<?import java.lang.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>

<BorderPane id="background" prefWidth="800.0" prefHeight="600.0" xmlns:fx="http://javafx.com/fxml">
    <top>
        <ToolBar>
            <Region styleClass="spacer" />
            <HBox styleClass="segmented-button-bar">
                <Button text="Tasks" styleClass="first" />
                <Button text="Administrator" />
                <Button text="Search" />
                <Button text="Line" />
                <Button text="Process" styleClass="last" />
            </HBox>
        </ToolBar>
    </top>
</BorderPane>

It’s the little things in life, really

One of Jasper’s favorite websites is called Dribbble, which is a place for designers to post whatever work they’re currently working on for others to view and be inspired from. I got hooked on Dribbble last Thursday and have been looking at a bunch of the mockups and itching to try implementing some of them in JavaFX. Here is my first attempt.

One of the use cases we used for our CSS support and our ToolBar API was that we wanted to support a style of toolbar button which (at least for me) was popularized on the Mac, which is referred to by Cocoa as a “segmented” button. This is essentially nothing more than an HBox of buttons that has been styled such that the first button has rounded left edges, the center buttons are squared up, and the last button has rounded right edges. In the image above by Bady, you can see the segmented button bar in the toolbar area of the application.

So to begin with, here is the Java code that goes into producing this app. This one is going to only have a toolbar, segmented button bar, and then the body area will just be the blue color you see in the above design. I actually will list two different examples here which both produce the same view and which both use the same CSS file. The first is just plain Java, while the second uses FXML to define the UI and a Java file simply loads the UI and configures the stage.

SegmentedButtonBarApp – Just Java

public class SegmentedButtonBarApp extends Application {
    @Override public void start(Stage stage) throws Exception {
        BorderPane root = new BorderPane();
        root.setId("background");

        ToolBar toolBar = new ToolBar();
        root.setTop(toolBar);

        Region spacer = new Region();
        spacer.getStyleClass().setAll("spacer");

        HBox buttonBar = new HBox();
        buttonBar.getStyleClass().setAll("segmented-button-bar");
        Button sampleButton = new Button("Tasks");
        sampleButton.getStyleClass().addAll("first");
        Button sampleButton2 = new Button("Administrator");
        Button sampleButton3 = new Button("Search");
        Button sampleButton4 = new Button("Line");
        Button sampleButton5 = new Button("Process");
        sampleButton5.getStyleClass().addAll("last", "capsule");
        buttonBar.getChildren().addAll(sampleButton, sampleButton2, sampleButton3, sampleButton4, sampleButton5);
        toolBar.getItems().addAll(spacer, buttonBar);

        Scene scene = new Scene(root, 800, 600);
        scene.getStylesheets().add(getClass().getResource("segmented.css").toExternalForm());
        stage.setScene(scene);
        stage.setTitle("Segmented Button Bar");
        stage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

SegmentedButtonBarFXMLApp.java and SegmentedButtonBar.fxml – Java and FXML

<?xml version="1.0" encoding="UTF-8"?>

<?import java.lang.*?>
<?import javafx.scene.control.*?>
<?import javafx.scene.layout.*?>

<BorderPane id="background" prefWidth="800.0" prefHeight="600.0" xmlns:fx="http://javafx.com/fxml">
    <top>
        <ToolBar>
            <items>
                <Region styleClass="spacer" />
                <HBox styleClass="segmented-button-bar">
                    <Button text="Tasks" styleClass="first" />
                    <Button text="Administrator" />
                    <Button text="Search" />
                    <Button text="Line" />
                    <Button text="Process" styleClass="last" />
                </HBox>
            </items>
        </ToolBar>
    </top>
</BorderPane>

public class SegmentedButtonBarFXMLApp extends Application{
    @Override public void start(Stage stage) throws Exception {
        Parent root = FXMLLoader.load(getClass().getResource("SegmentedButtonBar.fxml"));
        Scene scene = new Scene(root);
        scene.getStylesheets().add(getClass().getResource("segmented.css").toExternalForm());
        stage.setScene(scene);
        stage.setTitle("Segmented Button Bar From FXML");
        stage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

Both of these approach yield the same approach. I think the FXML file in this case is easier to visualize than reading the raw Java code, but either approach is valid. In both approaches you will notice that I have not done any visual styling whatsoever in the code or FXML, it has all been abstracted away to the css file. Here is what the application looks like without any CSS being applied.

So now lets apply one section of the CSS file at a time, and see how it modifies the look of the application.

The CSS

I started off by defining the following rule in CSS:

#background {
    -light-black: rgb(74, 75, 78);
    -dark-highlight: rgb(87, 89, 92);
    -dark-black: rgb(39, 40, 40);
    -darkest-black: rgb(5, 5, 5);
    -mid-gray: rgb(216, 222, 227);
    -fx-background-color: -mid-gray;
}

There are two things going on in this code. First, you will note that it selects only the node(s) with the id of “background”. The node in our scene graph with this id is the BorderPane which forms the root of the scene graph. The first chunk of the CSS file defines the color palette. In JavaFX CSS you can create arbitrary “variables” in your CSS by simply defining a declaration, such as -dark-black: rub(39, 40, 40);. Thereafter, you can refer to these named colors.

SegmentedButtonBar Palette

After doing nothing other than defining the color palette and the background, our app now looks like this:

The background now has this mid-gray color, while the rest of the app looks unchanged. Now, lets style the ToolBar.

.tool-bar {
    -fx-base: -dark-black;
    -fx-font-size: 12pt;
    -fx-background-color:
        linear-gradient(to bottom, derive(-fx-base,-30%), derive(-fx-base,-60%)),
        linear-gradient(to bottom, -light-black 2%, -dark-black 98%);
    -fx-background-insets: 0, 0 0 1 0;
    -fx-padding: .9em 0.416667em .9em 0.416667em;
    -fx-effect: dropshadow(two-pass-box,black,5,.2,0,0);
}

Here, I am selecting all toolbars in my app to be styled like this. I could have given my tool bar a special style class or ID so that I only targeted it, but in this case this is OK, since I am not using any other tool bars in my app, and if I were, I could style them explicitly by style class or ID if I wanted to. I am telling the toolbar to use the base color of -dark-black. I think the only reason for doing so is so that those automatically derived colors that I’m not about to override (of which I think only the text fill is ultimately going to be affected) will be styled correctly by default for being on a dark background. I’ve tweaked the font size to be a bit smaller (on mac it defaults to 13pt).

I’ve given the toolbar a new background gradient. It simply goes from top-to-bottom. I actually copied this out of caspian.css and then modified the main gradient (the second one in the list) to go from our -light-black palette color to our -dark-black gradient color. I tweaked the insets so that the border (the first gradient in the list) isn’t drawn on the bottom of the toolbar. I also tweaked the padding so that it would come out pretty close to the designer’s intent. Finally, I added a drop shadow.

Now that we’ve styled the tool bar, it is time to style the segmented buttons (that is, after all, what this post is supposed to be about!). Actually styling the segmented buttons is really pretty easy.

.segmented-button-bar .button {
    -fx-background-color:
        -darkest-black,
        -dark-highlight,
        linear-gradient(to bottom, -light-black 2%, -dark-black 98%);
    -fx-background-insets: 0, 1 1 1 0, 2 1 1 1;
    -fx-background-radius: 0;
    -fx-padding: 0.4em 1.833333em 0.4em 1.833333em;
}

.segmented-button-bar .button.first {
    -fx-background-insets: 0, 1, 2 1 1 1;
    -fx-background-radius: 3 0 0 3, 2 0 0 2, 2 0 0 2;
}

.segmented-button-bar .button.last {
    -fx-background-insets: 0, 1 1 1 0, 2 1 1 1;
    -fx-background-radius: 0 3 3 0, 0 2 2 0, 0 2 2 0;
}

.segmented-button-bar .button:pressed {
    -fx-background-color:
        -darkest-black,
        rgb(55, 57, 58),
        linear-gradient(to top, -light-black 2%, -dark-black 98%);
}

The segmented buttons are styled such that the first and last are half-rounded, and the middle buttons are squared up. With web CSS you have the “first-child” and “last-child” pseudo-classes. However these are not implemented in JavaFX, so instead I added the “first” and “last” style classes to the first and last buttons, respectively. This allows me to use a nice CSS rule to target them separately from any other random button added to the segmented button bar.

Oh, and my “segmented button bar” isn’t a control — it is just an HBox with some special CSS style. I gave the hbox the style class “segmented-button-bar”, and then here from CSS I will target all buttons that are within a segmented-button-bar, and style them specially.

The button is drawn using 3 overlapping background fills. The first is the dark outline, the second is the “highlight” — a lighter line draw to give the bezel look, and then the gradient that fills the rest of the body. The only trick with these is to correctly specify the insets and the corner radius’ so everything ends up looking right. Look closely at the following zoomed-in screenshot of the design:

You will notice that there is, on the left of this button, a black line and a highlight line. So does the black line belong to the button to the left of the “Search” button? Who draws it? In my case, I decided that the highlight line on the left would be drawn by this button, and the dark line on the right would also be drawn by this button. Thus you can butt multiple buttons against each other and they appear to “share” a border. Notice that the middle button draws the black lines on the top and bottom. So basically what I did was draw the black background, then draw a highlight background overtop of it adjusted such that it drew over most of the black background, just leaving 1 px on the top and bottom showing through. Then I drew the main fill adjusted so that the highlight was obscured except for 1 px on the top and left.

The first and last buttons were likewise tweaked to get the right look. The only additional thing done there was to make sure that the corner radius for the top-left and bottom-left edges (for the first button) were rounded and the top-right and bottom-right were squared. The same idea for the last button.

And that’s it. A SegmentedButtonBar where you can drop in buttons and they will be styled to match the colors, gradients, and so forth that the designer intended. And done by me: somebody who, unlike Jasper, isn’t very good at making a pretty UI

Oh, you may be wondering about that “spacer” region. I just gave it a simple style to push over the button bar a little ways.

.tool-bar .spacer {
    -fx-padding: 0 5.417em 0 0;
}

And finally, our app looks pretty good!

I started writing an article about how to write new UI controls for OpenJFX using all the internal APIs and architecture and so forth. But then I discovered that the control I was writing as a proof of concept was not using any private API at all, and actually was implementing the Skin differently than I had imagined previously, and I thought I ought to blog about it. Behold, the MoneyField!

The design space for a MoneyField is quite interesting. I did a bunch of research and tried out various different representations of “money” in Java, including Joda-Money, but in the end the parsing was not satisfactory and I concluded to just use a good old fashioned BigDecimal to represent a monetary value. The best blog I found talking about the issues with BigDecimal for representing Money is this one titled BigDecimal and Your Money. I think this same technique that I’m going to show works equally well whatever the data type is.

The most complex part of implementing this control was using the DecimalFormat for parsing the result back. In fact, I had a lot of trouble parsing the text in the MoneyField and producing a reliable BigDecimal out of it. I’m sure the implementation is lousy compared to what an expert in parsing such things could do, and I would welcome any feedback on my present implementation.

Writing the Control itself was trivial. I extended MoneyField from Control, and added a value property for holding the BigDecimal that would represent the monetary value of this control. I added a few other properties such as editable, promptText, and prefColumnCount. I also added an onAction event to MoneyField.

Now, there are some interesting things to talk about for you aspiring UI controls authors. Lets take a brief walk through the code.

public class MoneyField extends Control {
    /**
     * Creates a new MoneyField. The style class is set to "money-field".
     */
    public MoneyField() {
        getStyleClass().setAll("money-field");
    }

    @Override protected String getUserAgentStylesheet() {
        return getClass().getResource("MoneyField.css").toExternalForm();
    }
}

Every third party UI control must define the essential skeletal structure that you see in the above code snippet. You should provide a no-arg constructor (or it may not work in FXML). In your constructor, you should set the style class of the control to be the “css-ized” name of your control. Just toLowerCase and separate words by dashes. Then, because I want my skin to be entirely defined by CSS, I will override the getUserAgentStylesheet method and have it return a reference to a css file that I am going to define which acts as the “user agent stylesheet” for this control. That is, it provides the default CSS style for this control. Here is what my CSS file looks like:

#money-text-field {
    -fx-skin: "com.sun.javafx.scene.control.skin.TextFieldSkin";
}

.money-field {
    -fx-skin: "com.fxexperience.javafx.scene.control.skin.MoneyFieldSkin";
    -fx-background-color: -fx-shadow-highlight-color, -fx-text-box-border, -fx-control-inner-background;
    -fx-background-insets: 0, 1, 2;
    -fx-background-radius: 3, 2, 2;
    -fx-padding: 3 5 3 5;
    -fx-prompt-text-fill: derive(-fx-control-inner-background,-30%);
    -fx-cursor: text;
}

.money-field:focused {
    -fx-background-color: -fx-focus-color, -fx-text-box-border, -fx-control-inner-background;
    -fx-background-insets: -0.4, 1, 2;
    -fx-background-radius: 3.4, 2, 2;
}

.money-field:disabled {
    -fx-opacity: -fx-disabled-opacity;
}

There really isn’t a lot to say here, other than you can see I have a little trickery around the #money-text-field. Basically, I want the developer to be able to style the money field from CSS using .money-field, but I need to make sure the Skin used with the inner TextField is still a normal TextField. You’ll see how this fits together in a minute when I describe how the MoneyFieldSkin works.

Back in the MoneyField.java file, I also defined the above mentioned properties and events. First, here is what a “normal” property looks like. It is fully observable, readable, and writable.

    /**
     * The value of the MoneyField. If null, the value will be treated as "0", but
     * will still actually be null.
     */
    private ObjectProperty<BigDecimal> value = new SimpleObjectProperty<BigDecimal>(this, "value");
    public final BigDecimal getValue() { return value.get(); }
    public final void setValue(BigDecimal value) { this.value.set(value); }
    public final ObjectProperty<BigDecimal> valueProperty() { return value; }

I am using the SimpleObjectProperty, which takes as parameters a reference to the bean that defined it, and the name of the property. The value of the value property defaults to null. Our doclet produces javadoc on the getter and setter without having to actually write it manually, so that’s why docs are missing for those. The editable property is likewise defined as a SimpleBooleanProperty.

The onAction is a very straightforward implementation. If you write your own controls and want to include your own action events, it is very easy to do:

    /**
     * The action handler associated with this MoneyField, or
     * <tt>null</tt> if no action handler is assigned.
     *
     * The action handler is normally called when the user types the ENTER key.
     */
    private ObjectProperty<EventHandler<ActionEvent>> onAction = new ObjectPropertyBase<EventHandler<ActionEvent>>() {
        @Override protected void invalidated() {
            setEventHandler(ActionEvent.ACTION, get());
        }

        @Override public Object getBean() { return MoneyField.this; }
        @Override public String getName() { return "onAction"; }
    };
    public final ObjectProperty<EventHandler<ActionEvent>> onActionProperty() { return onAction; }
    public final EventHandler<ActionEvent> getOnAction() { return onActionProperty().get(); }
    public final void setOnAction(EventHandler<ActionEvent> value) { onActionProperty().set(value); }
}

You’ll notice that in the invalidated method of the property I call setEventHandler. This method exists for the registration of such event handlers with the system. Another interesting thing here is that I’m not extending SimpleObjectProperty, but rather I’m extending ObjectPropertyBase.

Every property must implement the getBean() and getName() method. SimpleXXX properties have fields which hold the bean & name, and you supply them in the constructor. But XXXPropertyBase properties have no such fields, and you must implement these methods. Why chose one over the other? Well, SimpleXXX properties will have smaller static footprint because they are using a class instead of defining a class, but will have larger dynamic footprint because they have two additional fields which must be saved for each instance. XXXPropertyBase uses larger static footprint because it defines a class, but smaller dynamic footprint because it doesn’t have to save these two fields. Since I had to subclass an object property anyway for the sake of implementing the invalidated method, I might as well extend ObjectPropertyBase and save a couple fields at runtime.

The Skin for MoneyField was quite interesting. At first I thought I would extend from TextFieldSkin (an internal implementation in JavaFX) but then discovered this wasn’t necessary. Instead, I could just implement the Skin interface and return a TextField as the “node” of the Skin. So the MoneyField defines my UI, and the TextField is actually what I end up using to represent the MoneyField. And then there is a pile of glue code which ties the TextField to the MoneyField. The other nice thing about this approach was that I could implement the entirety of MoneyField and MoneyFieldSkin without using any private API (which, when I started writing this, I didn’t think was possible).

public class MoneyFieldSkin implements Skin<MoneyField> {
    /**
     * The {@code Control} that is referencing this Skin. There is a
     * one-to-one relationship between a {@code Skin} and a {@code Control}.
     * When a {@code Skin} is set on a {@code Control}, this variable is
     * automatically updated.
     */
    private MoneyField control;

    /**
     * This textField is used to represent the MoneyField.
     */
    private TextField textField;

    /**
     * Create a new MoneyFieldSkin.
     * @param control The MoneyField
     */
    public MoneyFieldSkin(final MoneyField control) {
        this.control = control;

        // Create the TextField that we are going to use to represent this MoneyFieldSkin.
        // The textField restricts input so that only valid digits that contribute to the
        // Money can be input.
        textField = new TextField() { // ...
        };

        // ... and a lot more stuff!
    }

    @Override public MoneyField getSkinnable() {
        return control;
    }

    @Override public Node getNode() {
        return textField;
    }

    /**
     * Called by a Skinnable when the Skin is replaced on the Skinnable. This method
     * allows a Skin to implement any logic necessary to clean up itself after
     * the Skin is no longer needed. It may be used to release native resources.
     * The methods {@link #getSkinnable()} and {@link #getNode()}
     * should return null following a call to dispose. Calling dispose twice
     * has no effect.
     */
    @Override public void dispose() {
        textField = null;
    }

    // ... and a lot more stuff!
}

The above code lays out the very basic skeletal structure of a Skin. This skin implements the Skin interface directly. The constructor takes the MoneyField it will be working with, and creates the TextField which will represent the skin (or “draw” the skin). In the dispose method, we throw away the TextField.

If you ran the code above, you would find a MoneyField that looked and felt like a TextField. None of the properties on the MoneyField would work, but from a visual perspective and a text entry perspective you’d have, essentially, a TextField. The rest of MoneyFieldSkin is devoted to wiring up the MoneyField API to the TextField and implementing all the parsing and formatting necessary to make it look like a money field.

The remainder of the MoneyFieldSkin isn’t worth going through in this blog post, though you can download the Intellij project and check it out for yourself.

When Jonathan tried this out last night he was getting exceptions with the New Zealand currency. I suspect there may be problems in Australia too. I’m hoping one of our readers from down under will give it a look and see where my bug is .

Using the MoneyField is really very straightforward. I hope it is actually useful to boot. I’m wondering if anybody industrious out there might take this design strategy and write an EmailField and UrlField control, maybe a NumberField control too! It seems eminently doable using only the public API and would make a great addition to the ecosystem (as well as a great addition to the toolkit!).

I had some little sample I wanted to write where I had a TextField that restricted input. Maybe somebody else out there has already figured out how to do this elegantly, but I hadn’t and thought it would be worth a small post to demonstrate the technique.

Within the TextInputControl is a Content, which actually models the TextInputControl’s content. So for example, this is where we strip out newlines and such if you paste a String into a TextField that contains such characters, but in TextArea we allow those sorts of modifications. There is a protected getContent() method, so in theory a subclass of TextInputControl can manipulate the content directly, although in the case of TextField, it does not.

In fact, the only places in all the code that actually modify the TextField’s text is in the replaceText and replaceSelection methods defined on TextInputControl. So all you have to do is subclass TextField and override these two methods.

field = new TextField() {
    @Override public void replaceText(int start, int end, String text) {
        // If the replaced text would end up being invalid, then simply
        // ignore this call!
        if (!text.matches("[a-z]")) {
            super.replaceText(start, end, text);
        }
    }

    @Override public void replaceSelection(String text) {
        if (!text.matches("[a-z]")) {
            super.replaceSelection(text);
        }
    }
};

In the future we may want to add a more specific method (maybe called “accept” which takes the proposed new string after the modification) so that in the off chance that TextField or TextInputControl ends up modifying the content from some additional methods beyond these two, you could still have a reliable way to reject invalid input. However for the time being, this should work just fine!

Phil Race has posted a blog post over at the JavaFX Blog on the addition of LCD text support in the latest JavaFX 2.1 developer preview.

These intros become harder as the weeks go by. The core message is always the same: Enoy!

JavaFX

• It’s another week, so another developer preview release of JavaFX 2.1 is out for Linux, Mac OS and Windows. This week we are up to build 10.
• With the availability of JavaFX 2.1 developer preview builds for Linux, a number of people and news websites covered this. For example: Weigi Gao, Jaxenter, and H online.
• Jasper Potts has put up two blogs posts here at FX Experience. The first post discusses his work on extending the PathBuilder class to include more convenience methods, and secondly he has a post about extending the charts code shipped with JavaFX to apply curve fitting.
• Speaking of the builder classes shipped with JavaFX, Michael Heinrichs, a member of the JavaFX team, has put up a post about the advantages of the JavaFX builder APIs.
• Kevin Farnham put up a blog post over at Java.net about getting started with the JavaFX 2.1 developer preview on Linux.
• Dustin Marx talks about the @DefaultProperty annotation used in the JavaFX APIs, and what this means for you when building user interfaces with FXML.
• The GroovyFX library now has a new website.
• Thierry Janaudy has a blog post showing how to put a pie chart inside a TableView using a custom cell factory, whilst programming in Scala.
• Sébastien Bordes has a post detailing how to build and package JavaFX application with Maven.
• Narayan has blogged about the ‘include’ and ‘define’ tags in FXML.
• Yet another DatePicker control has appeared, pushing my count to at least five such controls. This week it belongs to Altuğ Uzunali.
• Andrew Krizhanovsky let me know about his wikokit project, which he describes as a “Machine-readable Wiktionary with GUI now ported to JavaFX 2.0. This version contains huge drop-down list of available languages.”

These conclusions are equally difficult. The core message is always the same: I hope you enjoy what I just linked to, and I hope it was good enough to see you again in a weeks time (where hopefully my introductions and conclusions are slightly more considered!)

I was experimenting today with extending AreaChart to do curve fitting for some example code I was hacking on. It is also a example of what can be done with styling JavaFX charts with CSS. Here is the result:

Curve Fitting

I have to admit I did not work out all the Math myself for the curve fitting I found a great article on CodeProject “Draw a Smooth Curve through a Set of 2D Points with Bezier Primitives”. Then ported the code to Java from C# and wired it up to our AreaChart. My version is not the most efficient as we do not yet have the correct API hooks to make it easy but we are thinking about how to add them. The current implementation extends AreaChart and overrides the layoutPlotChildren() method. That method creates all the nodes need for the chart and populates the node properties of the Series and Data items. So I can call super to let the standard code do its job then look at the Path elements for the stroked Path and filled Path that make up the AreaChart. I can then replace the LineTo elements with CubicCurveTo with the new control points calculated with the maths from the article. This way everything like auto ranging and animation still works as expected. The only waste is we are creating all the LineTo object and then throwing them away to replace them with CubicCurveTo objects. So here is the code that does this:

    /** @inheritDoc */
    @Override protected void layoutPlotChildren() {
        super.layoutPlotChildren();
        for (int seriesIndex=0; seriesIndex < getDataSize(); seriesIndex++) {
            final XYChart.Series<Number, Number> series = getData().get(seriesIndex);
            final Path seriesLine = (Path)((Group)series.getNode()).getChildren().get(1);
            final Path fillPath = (Path)((Group)series.getNode()).getChildren().get(0);
            smooth(seriesLine.getElements(), fillPath.getElements());
        }
    }

    private int getDataSize() {
        final ObservableList<XYChart.Series<Number, Number>> data = getData();
        return (data!=null) ? data.size() : 0;
    }

    private static void smooth(ObservableList<PathElement> strokeElements, ObservableList<PathElement> fillElements) {
        // as we do not have direct access to the data, first recreate the list of all the data points we have
        final Point2D[] dataPoints = new Point2D[strokeElements.size()];
        for (int i = 0; i < strokeElements.size(); i++) {
            final PathElement element = strokeElements.get(i);
            if (element instanceof MoveTo) {
                final MoveTo move = (MoveTo)element;
                dataPoints[i] = new Point2D(move.getX(), move.getY());
            } else if (element instanceof LineTo) {
                final LineTo line = (LineTo)element;
                final double x = line.getX(), y = line.getY();
                dataPoints[i] = new Point2D(x, y);
            }
        }
        // next we need to know the zero Y value
        final double zeroY = ((MoveTo) fillElements.get(0)).getY();

        // now clear and rebuild elements
        strokeElements.clear();
        fillElements.clear();
        Pair<Point2D[], Point2D[]> result = calcCurveControlPoints(dataPoints);
        Point2D[] firstControlPoints = result.getKey();
        Point2D[] secondControlPoints = result.getValue();
        // start both paths
        strokeElements.add(new MoveTo(dataPoints[0].getX(),dataPoints[0].getY()));
        fillElements.add(new MoveTo(dataPoints[0].getX(),zeroY));
        fillElements.add(new LineTo(dataPoints[0].getX(),dataPoints[0].getY()));
        // add curves
        for (int i = 1; i < dataPoints.length; i++) {
            final int ci = i-1;
            strokeElements.add(new CubicCurveTo(
                    firstControlPoints[ci].getX(),firstControlPoints[ci].getY(),
                    secondControlPoints[ci].getX(),secondControlPoints[ci].getY(),
                    dataPoints[i].getX(),dataPoints[i].getY()));
            fillElements.add(new CubicCurveTo(
                    firstControlPoints[ci].getX(),firstControlPoints[ci].getY(),
                    secondControlPoints[ci].getX(),secondControlPoints[ci].getY(),
                    dataPoints[i].getX(),dataPoints[i].getY()));
        }
        // end the paths
        fillElements.add(new LineTo(dataPoints[dataPoints.length-1].getX(),zeroY));
        fillElements.add(new ClosePath());
    }

CSS Styling

This is just the standard AreaChart in terms of the nodes its drawing with. The first part of the CSS is styling the main chart node and its background. We are using a dark gray texture as the background, adding a 1px black border and a drop shadow. Also adjusting the padding a little.

.chart {
    -fx-background-image: url("background.png");
    -fx-padding: 15 25 15 15;
    -fx-border-color: black;
    -fx-effect: dropshadow( gaussian , rgba(0,0,0,0.8) , 10, 0.0 , 0 , 2 );
}

Next we are looking at the background of the plot area, this is the rectangular area bordered by the two axis. We are using two background images here one a colored glow and the second is transparent white gridlines. The first image is sized to “cover” the whole area of the plot background and the second is tiled to fill. We also add black borders to the top and right to complete a box around the plot area including the two axis lines.

.chart-plot-background {
    -fx-background-image: url("chart-background.png"), url("graph-gridlines.png");
    -fx-background-size: cover, auto;
    -fx-background-repeat: no-repeat, repeat;
    -fx-background-position: 0% 0%, 0% 100%;
    -fx-border-color: black black transparent transparent;
}

The line that connects the data points we are styling to be 2px wide and white.

.chart-series-area-line {
    -fx-stroke: white;
    -fx-stroke-width: 2px;
}

The filled area under the line we are styling with a linear gradient from white on the left to 100% transparent white on the right. We also use a blend mode to get the desired effect when blending with the colored background of the plot area.

.chart-series-area-fill {
    -fx-fill: linear-gradient(to right, white, rgba(255,255,255,0));
    -fx-blend-mode: OVERLAY;
}

Making the plot symbols for each data point white.

.chart-area-symbol {
    -fx-background-color: white;
}

Hiding the tick marks and changing the color of the axis lines to black

.axis {
    -fx-tick-mark-visible: false;
    -fx-minor-tick-visible: false;
    -fx-tick-length: 3;
    -fx-minor-tick-length: 0;
    -fx-border-color: transparent;
}
.axis:bottom {
    -fx-border-color: black transparent transparent transparent;
}
.axis:left {
    -fx-border-color: transparent black transparent transparent;
}

Styling the text labels on the axis so they are white with black shadow and a little larger than default.

.axis Text{
    -fx-fill: white;
}
.tick-mark {
    -fx-font-size: 10px;
    -fx-effect: dropshadow( one-pass-box , rgba(0,0,0,0.8) , 0, 0.0 , 0 , 1 );
}

There you go that is all you need to take one of our standard charts and make it look completely different. Hopefully this will inspire some of you to try some exciting designs with JavaFX charts.

Source Code

The full Netbeans project and code including the maths is available here (CurveFittedChart.zip).

I came across the interesting blog “JavaFx and HTML5 differences” by Chika Okereke. Looking at the example code and comparing to the HTML Canvas version I thought the Java code could be made less verbose and easier to read.

Original Code

Path path_4 = new Path();
ObservableList shape_4 = path_4.getElements();
shape_4.add(new MoveTo(50,50));
shape_4.add(new LineTo(150,50));
shape_4.add(new LineTo(150,150));
shape_4.add(new LineTo(50,150));
shape_4.add(new LineTo(50,50));
path_4.setStrokeWidth(2);
path_4.setStroke(Color.rgb(255,0,0));

So I hacked together a Extended version of the PathBuilder that ships with JavaFX 2.0 adding methods for all of the path elements like moveTo() etc. The end result seems much cleaner code to me, what do you think?

Code with new Builder

Path path4 = PathBuilderExtended.create()
        .moveTo(50, 50)
        .lineTo(150, 50)
        .lineTo(150, 150)
        .lineTo(50, 150)
        .closePath()
        .strokeWidth(2)
        .stroke(Color.RED)
        .build();

This seemed a lot cleaner and simpler to read. I have filed a feature request RT-19266 in JIRA to add this to the platform. Feel free to comment on the bug if you any feedback or better suggestions. Also I have attached a implementation of this builder to the bug so you can see how it would be implemented or use it with your code today.

A heap of links this week (partly because I’m a day and a half late with this post!). Hopefully something for everyone

• JavaFX 2.1 developer preview build 09 has been released. For the first time, this release includes support for Windows, Mac OS, and Linux. You can read a bit more about this here.
  
• Amy Fowler’s “Interface Layout with JavaFX 2.0” JavaOne talk is now available on Parleys.
• Tom Schindl has created a SVG to FXML converter, which he plans to include in a future release of his e(fx)clipse project.
• Yet another JavaFX calendar control has been developed, this time by Christian Schudt. The control looks very nice and should be very useful to people needing this kind of functionality in their applications.
• Chika Okereke has put up three blogs posts about the JavaFX PDF support. The first two posts are about the NetBeans support, and then news about the latest release containing a few improvements.
• Dustin Marx has two blog posts this week. Firstly, he demonstrates FXML by porting one of his previous applications to use it, and secondly he reviews the “JavaFX 2.0: Introduction by Example” 2.0 book by Carl Dea.
• Thierry Janaudy has put up a blog post showing how to use the JavaFX TableView control in a GUI using Scala.
• Toni Epple has reviewed the JavaFX support in the latest 7.1 release of NetBeans.
• Sai Predeep Dandem has blogged about creating sliding effects (like those seen in the TitledPane control).
• Jim Weaver has put out a sample app that will be getting discussed in the upcoming Pro JavaFX 2.0 book.
• William Antônio Siqueira has blogged about the DataFX project, demonstrating how easy it is to get data into a JavaFX TableView control.

Catch you all in a weeks time.