The answer is quite simple: wrap the cell factory inside another cell factory, and set the ContextMenu on the wrapping cell. In other words, you would write code such as this (for ListView):

// The cell factory you actually want to use to render the cell
Callback<ListView<T>, ListCell<T> wrappedCellFactory = ...; 

// The wrapping cell factory that will set the context menu onto the wrapped cell
Callback<ListView<T>, ListCell<T> cellFactory = new Callback<ListView<T>, ListCell<T>>() {
    @Override public ListCell<T> call(ListView<T> listView) {
        ListCell<T> cell = cellFactory == null ? new DefaultListCell<T>() : wrappedCellFactory.call(listView);
        cell.setContextMenu(contextMenu);
        return cell;
    }
};

// Creating a ListView and setting the cell factory on it
ListView<T> listView = new ListView<T>();
listView.setCellFactory(cellFactory);

Before I get any further, I should note quickly that this blog post is about ListView / ListCell, but the exact same approach (and even code – barring a little bit of renaming) is still totally applicable to TreeView and TableView.

One thing to note in the code above is the use of DefaultListCell, which is defined below. I made a new class as I was working on this problem, but I just copy/pasted the code out of ListViewSkin for creating default ListCell instances when the end-developer has not installed a custom cell factory. DefaultListCell therefore just handles the most common case of showing text and/or a ‘graphic’ (which can be an arbitrarily complex scenegraph node):

import javafx.scene.Node;
import javafx.scene.control.ListCell;

public class DefaultListCell<T> extends ListCell<T> {
    @Override public void updateItem(T item, boolean empty) {
        super.updateItem(item, empty);

        if (empty) {
            setText(null);
            setGraphic(null);
        } else if (item instanceof Node) {
            setText(null);
            Node currentNode = getGraphic();
            Node newNode = (Node) item;
            if (currentNode == null || ! currentNode.equals(newNode)) {
                setGraphic(newNode);
            }
        } else {
            setText(item == null ? "null" : item.toString());
            setGraphic(null);
        }
    }
}

Of course, I’m not going to leave you with just the code above! We have to make a more useful API out of this (this is my day job after all)! Therefore, borrowing from the style of the cell factories that are shipping with JavaFX 2.2, I present to you the following sample:

import javafx.scene.control.ContextMenu;
import javafx.scene.control.ListCell;
import javafx.scene.control.ListView;
import javafx.util.Callback;

/**
 * A fully fleshed out class that allows for context menus to be shown on right click.
 */
public class ContextMenuListCell<T> extends ListCell<T> {

    public static <T> Callback<ListView<T>,ListCell<T>> forListView(ContextMenu contextMenu) {
        return forListView(contextMenu, null);
    }

    public static <T> Callback<ListView<T>,ListCell<T>> forListView(final ContextMenu contextMenu, final Callback<ListView<T>,ListCell<T>> cellFactory) {
        return new Callback<ListView<T>,ListCell<T>>() {
            @Override public ListCell<T> call(ListView<T> listView) {
                ListCell<T> cell = cellFactory == null ? new DefaultListCell<T>() : cellFactory.call(listView);
                cell.setContextMenu(contextMenu);
                return cell;
            }
        };
    }

    public ContextMenuListCell(ContextMenu contextMenu) {
        setContextMenu(contextMenu);
    }
}

Now that we have a simple API, we can proceed to use this API along the following lines:

// Create a MenuItem and place it in a ContextMenu
MenuItem helloWorld = new MenuItem("Hello World!");
ContextMenu contextMenu = new ContextMenu(helloWorld);

// sets a cell factory on the ListView telling it to use the previously-created ContextMenu (uses default cell factory)
listView.setCellFactory(ContextMenuListCell.<Person>forListView(contextMenu));

// Same as above, but uses a custom cell factory that is defined elsewhere
listView.setCellFactory(ContextMenuListCell.<Person>forListView(contextMenu, customCellFactory));

This results in the following when a user right-clicks on a cell in the ListView:

However, we’re left with one final issue: we need a way to determine which cell was selected when a MenuItem action is fired. Fortunately, this proves to be trivial: simply refer to the ListView selection model, as selection also changes on right-click (which in some ways is a bug, but for now it suits our needs). Here’s some sample code:

helloWorld.setOnAction(new EventHandler<ActionEvent>() {
    @Override public void handle(ActionEvent e) {
        System.out.println("Selected item: " + listView.getSelectionModel().getSelectedItem());
    }
});

And that’s that! . Hopefully this is helpful to people out there. I’m sure you’ll have questions and comments – feel free to leave them on this post so that others may also learn.

Non-editable and editable ComboBox controls of all shapes and sizes!

In the screenshot above you can see what the default ComboBox looks like. On the left you can see three non-editable ComboBox controls, and on the right you see three editable ComboBox controls. The default width of a ComboBox is based on the width of the content of the ComboBox, so that the menu appears as roughly the same width. You’ll note that the bottom-left ComboBox has a different font – this is because this ComboBox has a cell factory set on it, which is something I’ll cover shortly.

A quick detour: What is ComboBoxBase?

The ComboBox control is an extension of the ComboBoxBase class. For most developers this distinction is unnecessary, but for those of you wanting to write your own ComboBox-like control (which I hope is many ), the following is worth reading. The ComboBoxBase class is an abstract class, whose goal is to represent the core concept of what a combo box is. ComboBoxBase brings the basic API expected across all combo box implementations. Firstly, it has a value property, which represents either the latest selection the user has made, or the latest input they have provided in the case of editable combo boxes. It also has the show() and hide() methods you would expect. The third key piece of API is the editable property, which specifies whether the ComboBox should allow user input. There is other API also, but what I’ve mentioned here is the core of it.

As mentioned above, ComboBoxBase is intended to represent the nature of all combo boxes – that is, a combo box is generically a button that, when clicked or otherwise prompted, shows to the user a number of choices. Examples of other, ComboBox-like controls include calendar pickers and colour choosers, but even extends to use cases where entire dialogs are popped-up on clicking. The ComboBoxBase does not pretend to know what happens when show() and hide() are called, and that is left up to subclasses whose skin extends the abstract ComboBoxBaseSkin class. For more information, refer to the ComboBox class and its ComboBoxListViewSkin skin class in OpenJFX. If all else fails,  leave a comment on this post or email me with your questions.

To cement what I mean in the above two paragraphs, the ComboBox class extends ComboBoxBase to provide the most commonly used ComboBox form, which is the kind that displays a popup list from which a user may choose one option. You can see what the popup list looks like in ComboBox in the screenshot below.

A non-editable ComboBox with a popup list showing

ComboBox API

The ComboBox control in JavaFX 2.1 has a very familiar API to anyone who has built user interfaces in JavaFX 2.0. It brings with it API from ListView, Button, ChoiceBox, and even a little bit of TextField. For example, ComboBox borrows from ListView (as well as TableView and ChoiceBox) the concept of having an items list that contains all elements to show to the user. The generic type of the ComboBox represents the type of the items list. In addition to this, ComboBox has a cell factory using exactly the same API (including ListCell) as the ListView control. This is why in the first screenshot above you see the bottom-left button has a different font – it is actually Cooper Black, as the bottom-left ComboBox has been populated with the fonts found on my computer. What this means is that the cell factory is used not just for the popup list, but it is also used in the ComboBox ‘button’ itself. Check out the screenshot below to understand better.

A ComboBox with a custom cell factory

Another very useful addition to the ComboBox API (and one which has been retrofitted into the ChoiceBox API as well) is the support for StringConverter implementations (which in reality deserves its own blog post to detail the availability of the javafx.util.converter package and the ability to use these converters in the binding API as of JavaFX 2.1. Maybe Michael Heinrichs might cover this, *hint* ). A StringConverter does exactly what the name suggests: it has two methods, one that takes an Object and returns a String, and the other that takes a String and attempts to return an Object. StringConverter implementations are therefore used within ComboBox for two purposes. Firstly, the ComboBox items list (and the text on the ComboBox button), when displayed to the user, is run through the StringConverter before being displayed. Secondly, it takes the commited text input and attempts to convert it to a object that can then be set in the value property.

The ComboBox makes use of the familiar SelectionModel API that is present in a number of other controls such as ListView, TreeView, TableView, ChoiceBox, TabPane, etc, and it works in the same way. One important point to note is that the ComboBox selection model is a SingleSelectionModel, so the ComboBox control will only ever support single selection. A future, separate control (e.g. ListBox or similar) might support multiple selection.

Conclusion

Hopefully with this post you’ll have a better understanding of what the ComboBox in JavaFX 2.1 can do. If you have any questions, please leave a comment on this post. If you find a bug, please file it in Jira.

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!

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 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.

The Design

I started the design with a free Photoshop file from Diego Monzon:

You will see that some of it like the cool VU meters made it direct though to my design but then I played around with the other parts. I have added a link to the Photoshop file I created so you can see what I have done if you are intrested. From the photoshop file I produced a few PNG files which are used in the application, you can see them in the src images directory. I found a free LCD dot matrix font from dafont which is what I am using for the text on the screen. You can see in the code how this is loaded in JavaFX.

Download the Photoshop File 18Mb

The Code

The application did not take that long to build, guess about a day in total and about 800 lines of code. I think it is fully working other than the balance is a little fiddly with the mouse. All the control customizations should have full keyboard navigation . It is mostly standard UI Controls just styled with Images and CSS. The round knobs like balance and volume I had to do something special for and created a knob skin for the Slider control. There was a bunch of the standard logic to load and parse M3U and XML playlists, a very simple data model object PlayList which just contains a url which it was loaded from and a observable list of Pairs, each Pair being a name for the song and a url to the song. We did not have all the low level media API I needed for the VU meters but as they are only really for show I made of some data from what we can get from AudioSpectrumListener.

Download the source and Netbeans Project 1.5Mb

Hope you enjoy playing with this fun little app as much as I did creating it. Hope it goes to show that you can create pretty much any UI that you can imagine in JavaFX 2.0 and even use standard controls so you maintain keyboard navigation, accessibility etc.

All of these are mostly created with multiple background fill layers each with a gradient. Then there is a little font tweaking and some subtle effects. So for example all you need to make a JavaFX button look like a Windows 7 button is:

#windows7-default {
    -fx-background-color:
        #3c7fb1,
        linear-gradient(#fafdfe, #e8f5fc),
        linear-gradient(#eaf6fd 0%, #d9f0fc 49%, #bee6fd 50%, #a7d9f5 100%);
    -fx-background-insets: 0,1,2;
    -fx-background-radius: 3,2,1;
    -fx-padding: 3 30 3 30;
    -fx-text-fill: black;
    -fx-font-size: 14px;
}

The first line defines the 3 background fills, first is solid color and the other two are linear gradients. The background-insets offsets the backgrounds so they do not 100% paint over each other and the second background is 1px in from the outside and the 3rd background is 2px in from the outside of the button. The background-radius us setting the corner radius’s of the 3 backgrounds getting smaller as the backgrounds move in, this makes the gap between the borders a consistent 1 pixel all the way around. Padding adds extra space around the text to make the button bigger by default. Then the last two lines set the text color and size. That is all there is too it.

I have not included styles for the pressed, over and focused states of all the buttons but they can all be easily added in a similar way. I have included a over and pressed state for the “Record Sales” button as a example.

You can download the complete Netbeans project with all the code here.
ButtonStyles.zip

Here is the CSS code of all the button styles you see above:

#green {
    -fx-background-color:
        linear-gradient(#f0ff35, #a9ff00),
        radial-gradient(center 50% -40%, radius 200%, #b8ee36 45%, #80c800 50%);
    -fx-background-radius: 6, 5;
    -fx-background-insets: 0, 1;
    -fx-effect: dropshadow( three-pass-box , rgba(0,0,0,0.4) , 5, 0.0 , 0 , 1 );
    -fx-text-fill: #395306;
}
#round-red {
    -fx-background-color: linear-gradient(#ff5400, #be1d00);
    -fx-background-radius: 30;
    -fx-background-insets: 0;
    -fx-text-fill: white;
}
#bevel-grey {
    -fx-background-color:
        linear-gradient(#f2f2f2, #d6d6d6),
        linear-gradient(#fcfcfc 0%, #d9d9d9 20%, #d6d6d6 100%),
        linear-gradient(#dddddd 0%, #f6f6f6 50%);
    -fx-background-radius: 8,7,6;
    -fx-background-insets: 0,1,2;
    -fx-text-fill: black;
    -fx-effect: dropshadow( three-pass-box , rgba(0,0,0,0.6) , 5, 0.0 , 0 , 1 );
}
#glass-grey {
    -fx-background-color:
        #c3c4c4,
        linear-gradient(#d6d6d6 50%, white 100%),
        radial-gradient(center 50% -40%, radius 200%, #e6e6e6 45%, rgba(230,230,230,0) 50%);
    -fx-background-radius: 30;
    -fx-background-insets: 0,1,1;
    -fx-text-fill: black;
    -fx-effect: dropshadow( three-pass-box , rgba(0,0,0,0.6) , 3, 0.0 , 0 , 1 );
}
#shiny-orange {
    -fx-background-color:
        linear-gradient(#ffd65b, #e68400),
        linear-gradient(#ffef84, #f2ba44),
        linear-gradient(#ffea6a, #efaa22),
        linear-gradient(#ffe657 0%, #f8c202 50%, #eea10b 100%),
        linear-gradient(from 0% 0% to 15% 50%, rgba(255,255,255,0.9), rgba(255,255,255,0));
    -fx-background-radius: 30;
    -fx-background-insets: 0,1,2,3,0;
    -fx-text-fill: #654b00;
    -fx-font-weight: bold;
    -fx-font-size: 14px;
    -fx-padding: 10 20 10 20;
}
#dark-blue {
    -fx-background-color:
        #090a0c,
        linear-gradient(#38424b 0%, #1f2429 20%, #191d22 100%),
        linear-gradient(#20262b, #191d22),
        radial-gradient(center 50% 0%, radius 100%, rgba(114,131,148,0.9), rgba(255,255,255,0));
    -fx-background-radius: 5,4,3,5;
    -fx-background-insets: 0,1,2,0;
    -fx-text-fill: white;
    -fx-effect: dropshadow( three-pass-box , rgba(0,0,0,0.6) , 5, 0.0 , 0 , 1 );
    -fx-font-family: "Arial";
    -fx-text-fill: linear-gradient(white, #d0d0d0);
    -fx-font-size: 12px;
    -fx-padding: 10 20 10 20;
}
#dark-blue Text {
    -fx-effect: dropshadow( one-pass-box , rgba(0,0,0,0.9) , 1, 0.0 , 0 , 1 );
}
#record-sales {
    -fx-padding: 8 15 15 15;
    -fx-background-insets: 0,0 0 5 0, 0 0 6 0, 0 0 7 0;
    -fx-background-radius: 8;
    -fx-background-color:
        linear-gradient(from 0% 93% to 0% 100%, #a34313 0%, #903b12 100%),
        #9d4024,
        #d86e3a,
        radial-gradient(center 50% 50%, radius 100%, #d86e3a, #c54e2c);
    -fx-effect: dropshadow( gaussian , rgba(0,0,0,0.75) , 4,0,0,1 );
    -fx-font-weight: bold;
    -fx-font-size: 1.1em;
}
#record-sales:hover {
    -fx-background-color:
        linear-gradient(from 0% 93% to 0% 100%, #a34313 0%, #903b12 100%),
        #9d4024,
        #d86e3a,
        radial-gradient(center 50% 50%, radius 100%, #ea7f4b, #c54e2c);
}
#record-sales:pressed {
    -fx-padding: 10 15 13 15;
    -fx-background-insets: 2 0 0 0,2 0 3 0, 2 0 4 0, 2 0 5 0;
}
#record-sales Text {
    -fx-fill: white;
    -fx-effect: dropshadow( gaussian , #a30000 , 0,0,0,2 );
}
#rich-blue {
    -fx-background-color:
        #000000,
        linear-gradient(#7ebcea, #2f4b8f),
        linear-gradient(#426ab7, #263e75),
        linear-gradient(#395cab, #223768);
    -fx-background-insets: 0,1,2,3;
    -fx-background-radius: 3,2,2,2;
    -fx-padding: 12 30 12 30;
    -fx-text-fill: white;
    -fx-font-size: 12px;
}
#rich-blue Text {
    -fx-effect: dropshadow( one-pass-box , rgba(0,0,0,0.8) , 0, 0.0 , 0 , 1);
}
#big-yellow {
    -fx-background-color:
        #ecebe9,
        rgba(0,0,0,0.05),
        linear-gradient(#dcca8a, #c7a740),
        linear-gradient(#f9f2d6 0%, #f4e5bc 20%, #e6c75d 80%, #e2c045 100%),
        linear-gradient(#f6ebbe, #e6c34d);
    -fx-background-insets: 0,9 9 8 9,9,10,11;
    -fx-background-radius: 50;
    -fx-padding: 15 30 15 30;
    -fx-font-family: "Helvetica";
    -fx-font-size: 18px;
    -fx-text-fill: #311c09;
    -fx-effect: innershadow( three-pass-box , rgba(0,0,0,0.1) , 2, 0.0 , 0 , 1);
}
#big-yellow Text {
    -fx-effect: dropshadow( one-pass-box , rgba(255,255,255,0.5) , 0, 0.0 , 0 , 1);
}
#iphone-toolbar {
    -fx-background-color: linear-gradient(#98a8bd 0%, #8195af 25%, #6d86a4 100%);
}
#iphone {
    -fx-background-color:
        #a6b5c9,
        linear-gradient(#303842 0%, #3e5577 20%, #375074 100%),
        linear-gradient(#768aa5 0%, #849cbb 5%, #5877a2 50%, #486a9a 51%, #4a6c9b 100%);
    -fx-background-insets: 0 0 -1 0,0,1;
    -fx-background-radius: 5,5,4;
    -fx-padding: 7 30 7 30;
    -fx-text-fill: #242d35;
    -fx-font-family: "Helvetica";
    -fx-font-size: 12px;
    -fx-text-fill: white;
}
#iphone Text {
    -fx-effect: dropshadow( one-pass-box , rgba(0,0,0,0.8) , 0, 0.0 , 0 , -1 );
}
#ipad-dark-grey {
    -fx-background-color:
        linear-gradient(#686868 0%, #232723 25%, #373837 75%, #757575 100%),
        linear-gradient(#020b02, #3a3a3a),
        linear-gradient(#9d9e9d 0%, #6b6a6b 20%, #343534 80%, #242424 100%),
        linear-gradient(#8a8a8a 0%, #6b6a6b 20%, #343534 80%, #262626 100%),
        linear-gradient(#777777 0%, #606060 50%, #505250 51%, #2a2b2a 100%);
    -fx-background-insets: 0,1,4,5,6;
    -fx-background-radius: 9,8,5,4,3;
    -fx-padding: 15 30 15 30;
    -fx-font-family: "Helvetica";
    -fx-font-size: 18px;
    -fx-font-weight: bold;
    -fx-text-fill: white;
    -fx-effect: dropshadow( three-pass-box , rgba(255,255,255,0.2) , 1, 0.0 , 0 , 1);
}
#ipad-dark-grey Text {
    -fx-effect: dropshadow( one-pass-box , black , 0, 0.0 , 0 , -1 );
}
#ipad-grey {
    -fx-background-color:
        linear-gradient(#686868 0%, #232723 25%, #373837 75%, #757575 100%),
        linear-gradient(#020b02, #3a3a3a),
        linear-gradient(#b9b9b9 0%, #c2c2c2 20%, #afafaf 80%, #c8c8c8 100%),
        linear-gradient(#f5f5f5 0%, #dbdbdb 50%, #cacaca 51%, #d7d7d7 100%);
    -fx-background-insets: 0,1,4,5;
    -fx-background-radius: 9,8,5,4;
    -fx-padding: 15 30 15 30;
    -fx-font-family: "Helvetica";
    -fx-font-size: 18px;
    -fx-font-weight: bold;
    -fx-text-fill: #333333;
    -fx-effect: dropshadow( three-pass-box , rgba(255,255,255,0.2) , 1, 0.0 , 0 , 1);
}
#ipad-grey Text {
    -fx-effect: dropshadow( one-pass-box , white , 0, 0.0 , 0 , 1 );
}
#lion-default {
    -fx-background-color:
        rgba(0,0,0,0.08),
        linear-gradient(#5a61af, #51536d),
        linear-gradient(#e4fbff 0%,#cee6fb 10%, #a5d3fb 50%, #88c6fb 51%, #d5faff 100%);
    -fx-background-insets: 0 0 -1 0,0,1;
    -fx-background-radius: 5,5,4;
    -fx-padding: 3 30 3 30;
    -fx-text-fill: #242d35;
    -fx-font-size: 14px;
}
#lion {
    -fx-background-color:
        rgba(0,0,0,0.08),
        linear-gradient(#9a9a9a, #909090),
        linear-gradient(white 0%, #f3f3f3 50%, #ececec 51%, #f2f2f2 100%);
    -fx-background-insets: 0 0 -1 0,0,1;
    -fx-background-radius: 5,5,4;
    -fx-padding: 3 30 3 30;
    -fx-text-fill: #242d35;
    -fx-font-size: 14px;
}
#windows7-default {
    -fx-background-color:
        #3c7fb1,
        linear-gradient(#fafdfe, #e8f5fc),
        linear-gradient(#eaf6fd 0%, #d9f0fc 49%, #bee6fd 50%, #a7d9f5 100%);
    -fx-background-insets: 0,1,2;
    -fx-background-radius: 3,2,1;
    -fx-padding: 3 30 3 30;
    -fx-text-fill: black;
    -fx-font-size: 14px;
}
#windows7 {
    -fx-background-color:
        #707070,
        linear-gradient(#fcfcfc, #f3f3f3),
        linear-gradient(#f2f2f2 0%, #ebebeb 49%, #dddddd 50%, #cfcfcf 100%);
    -fx-background-insets: 0,1,2;
    -fx-background-radius: 3,2,1;
    -fx-padding: 3 30 3 30;
    -fx-text-fill: black;
    -fx-font-size: 14px;
}

A TableView control using default styling and API as provided in JavaFX 2.0.

Or, more specifically, why it doesn’t look like this:

A TableView without alternate row highlighting in empty rows

I can see where this question comes from, given this is how Swing’s JTable looks:

Swing JTable

It comes down to taste I guess, but given that there is a subset of developers who expect this look, I thought I’d put a blog post up here to clarify how it is done (and to save me having to explain it to people individually by email!) All you need is the following CSS for TableView:

.table-row-cell:empty {
    -fx-background-color: white;
}

.table-row-cell:empty .table-cell {
    -fx-border-width: 0px;
}

Similarly, for ListView, you can get away with just the first statement above (slightly modified for ListView):

.list-cell:empty {
    -fx-background-color: white;
}

The end result is precisely what you see in the second image above (there ain’t no photoshop trickery here!) Hopefully this helps people customising their user interfaces, and hopefully also encourages you to further explore what is possible. The best starting point is the excellent JavaFX documentation website, the CSS Reference (which is about to be updated for 2.0.2 I believe), and as always, the caspian.css file that ships with every JavaFX release (embedded within jfxrt.jar).

DataFX is a project Johan Vos and I have been working on for many months now, and it has gone through a number of iterations in that time. At JavaOne 2011 we put out a first release (let’s call it version 0.0.1 for lack of an official version number), and today I want to briefly introduce it for those of you who didn’t attend JavaOne. However, even if you didn’t attend JavaOne, we’ve put the slides online.

To be very clear, DataFX is not an Oracle project! Johan and I both developed this in our own time, and it does not necessarily represent the future plans of the official JavaFX project. This project was built to make many of the UI controls I develop easier to work with by filling in the gaps as of the current JavaFX 2.0 release. Oracle may or may not have future plans in the same area as DataFX, but for now DataFX exists to fill the gap. For more details, check out the DataFX FAQ.

To make things easier to understand let’s conceptually split DataFX into two sub-projects which attack a common problem from two different angles.

Data Sources

The first sub-project deals with the logistics of getting data into the user interface controls by providing various data source adapters. These adapters are intended to provide convenience around populating JavaFX controls such as ListView and TableView (at this stage, although we’d love to eventually also support populating TreeView and charts). This is achieved by abstracting away the implementation details surrounding data source retrieval and massaging, such that data can be rapidly loaded and seen on screen. This is done by essentially creating data sources that are ObservableList instances, allowing for them to be directly loaded into the ListView and TableView ‘items’ property. In the case of TableView, DataFX can also auto-generate TableColumn instances with pre-built cell value factories defined.

DataSourceReader dsr1 = new FileReader("foo.xml");
DataSourceReader dsr2 = new NetworkReader ("http://foo.bar/foo.xml");

XmlDataSource ds1 = new XmlDataSource(dsr1);

TableView tableView = new TableView();
tableView.setItems(ds1);
tableView.getColumns().addAll(ds1.getColumns());

An example of how to use this API is shown above. We define two DataSourceReader instances: one is a FileReader, the other a NetworkReader (although in this example the NetworkReader isn’t used any further). In both cases it is important to note that the DataSourceReader is datatype-agnostic – that is, it only cares about where the data is coming from, not the format of the data. At present DataFX only ships with these two DataSourceReader implementations, but it is probable that over time we will add more classes. You can see the JavaDoc for these classes in the org.javafxdata.datasources.io package.

Once the DataSourceReader instance is created, we must then create a DataSource using one of the implementations provided in the org.javafxdata.datasources.protocol package. In the example below, we create an XmlDataSource, which knows how to parse an XML data stream and create an ObservableList that can be set directly into a ListView or TableView. Also, because it extends TableWrapper, it has a getColumns() method that can be used to set the columns in a TableView instance. At present, we have DataSource implementations for CSV files, Java Objects, RedFX and XML files. Again, we intend to add further data source implementations in the future as time permits.

Now that the DataSource exists, we create a TableView instance, and set the items property to be the data source itself. We also add all the columns the data source generates into the TableView columns property. This not only creates a column header with default text, it also creates a default cell value factory to populate the cells in that column. This is often the most complex part of using a TableView, and is completely unnecessary in data sources by default (of course, you are free to just create your own TableColumn instances also).

With a (by default) version number of 0.0.1, we recognise that DataFX is not a finished product. For one, it never will be – it’s a free project that we are making available here – but also we recognise the gaping holes in the data sources sub-project. In particular, along with what I’ve listed above, we also want to provide much more convenience around features such as sorting, filtering, and on-demand loading. If there is anything else that you think is missing, you can find the contact details over at the DataFX website.

Cell Factories

A TreeView with support for CheckBoxes

The other sub-project of the DataFX project is dealing with the need to more easily visualise data once it is already appearing inside the ListView, TreeView and TableView controls. This customisation is done almost entirely using the cell factories API that is available in all three controls (I’ll try to blog more about cell factories in a future post). In other words, the default cell factory implementation provided by ListView/TreeView/TableView is sometimes not sufficient – it simply calls toString() on the data objects and shows it onscreen. In these circumstances, it is necessary to provide your own cell factory, and this is where DataFX comes in – it provides a number of useful cell factories that you can drop in and use, often with only one line of code.

There are a number of pre-built custom cells. You can see the full list on the cell factories page on the DataFX website, but briefly, it includes the following:

• TextField (for text editing)
• ChoiceBox (for selecting between a small number of choices)
• CheckBox (for toggling a boolean property)
• ProgressBar (for graphically representing a number as it progresses from 0.0 to 1.0)
• Money formatting (formats a Number instance using a default Locale, and applies CSS to make negative values red, and positive values green)
• Dynamically variable row heights (e.g. on mouse hover, a row will grow to show more information)

For each cell type mentioned above, there is a separate static factory class that contains a number of convenience methods. These methods should be your first port of call. You can find both the cells, and the more convenient cell factories API in the org.javafxdata.control.cell package. You should explore these javadocs as I have spent considerable effort ensuring that they contain all necessary information. For screenshots of all the cell factories currently available, you can go to the cell factories page on the DataFX website (clicking on the ticks will take you to a screenshot for that feature – I’ll try to make this more intuitive when I have time). I’ve attached one screenshot to this blog post, for the CheckBox TreeView.

In the code snippet below, I demonstrate how simple it is to make a ListView support text editing of cells when the user double-clicks on a row. In particular, note that the last line is the only line that uses the DataFX API (i.e. the reference to TextFieldCellFactory is from DataFX) – the other three lines are normal ListView API that should already be familiar to many developers.

ListView<String> listView = new ListView<String>();
listView.setItems(namesList);
listView.setEditable(true);
listView.setCellFactory(TextFieldCellFactory.forListView());

Again, the cell factories implementation certainly lacks features, but we think it provides a good starting point for the most common use cases. If there is a cell factory you think is missing, get in touch and let us know – we may just build it for you!

Conclusion

Johan and I both hope that DataFX is useful to you. We welcome feedback and requests for features – our goal is to make development of rich user interfaces in JavaFX 2.0 as simple as possible. Any use cases you can share with us will be much appreciated as we continue to refine our APIs, as well as provide additional data sources and cell factory implementations.

In the very, very late stages of the JavaFX 2.0 EA program, we decided we didn’t really like this API all that much. The concept of having both left/right and top/bottom just didn’t really gel with us. After some discussion, we thought we’d use the same API style as we do elsewhere in JavaFX 2.0: expose a collection and allow for developers to place their content into it. This mean that to use a SplitPane, you’d use code such as the following:

import javafx.application.Application;
import javafx.geometry.Orientation;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.Button;
import javafx.scene.control.SplitPane;
import javafx.scene.layout.HBox;
import javafx.scene.paint.Color;
import javafx.stage.Stage;

public class SplitPaneSample extends Application {

    @Override public void start(Stage stage) {
        HBox hbox = new HBox(20);
        hbox.setTranslateX(20);
        hbox.setTranslateY(20);

        SplitPane splitPane1 = new SplitPane();
        splitPane1.setPrefSize(200, 200);
        final Button l = new Button("Left Button");
        final Button r = new Button("Right Button");
        splitPane1.getItems().addAll(l, r);
        hbox.getChildren().add(splitPane1);

        Scene scene = new Scene(new Group(hbox), 560, 240);
        scene.setFill(Color.GHOSTWHITE);
        stage.setScene(scene);
        stage.setTitle("SplitPane");
        stage.setVisible(true);
    }

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

The main segment of code is the middle block, where we create a SplitPane, set a preferred size, and add in the two buttons we want to display. I hope you see where I’m going with this: now that we aren’t constrained to just having ‘left’ and ‘right’ nodes, we can actually put in any number of nodes into the items collection – and the SplitPane will automatically create N – 1 dividers. For example:

        SplitPane splitPane2 = new SplitPane();
        splitPane2.setPrefSize(300, 200);
        final Button l2 = new Button("Left Button");
        final Button c2 = new Button("Center Button");
        final Button r2 = new Button("Right Button");
        splitPane2.getItems().addAll(l2, c2, r2);
        hbox.getChildren().add(splitPane2);

The result of this code is shown in the second SplitPane you see in the picture above. Now, a SplitPane wouldn’t be all that great if it only allows for the SplitPane content to run in a horizontal flow, so we also support setting an orientation on the SplitPane. As mentioned, the default value is HORIZONTAL, which is what you see in the screenshot above. You can also set it to VERTICAL, which you can see in the screenshot below.

        SplitPane splitPane1 = new SplitPane();
        splitPane1.setOrientation(Orientation.VERTICAL);
        splitPane1.setPrefSize(200, 200);
        final Button l1 = new Button("Left Button");
        final Button r1 = new Button("Right Button");
        splitPane1.getItems().addAll(l1, r1);
        hbox.getChildren().add(splitPane1);

        SplitPane splitPane2 = new SplitPane();
        splitPane2.setOrientation(Orientation.VERTICAL);
        splitPane2.setPrefSize(300, 200);
        final Button l2 = new Button("Left Button");
        final Button c2 = new Button("Center Button");
        final Button r2 = new Button("Right Button");
        splitPane2.getItems().addAll(l2, c2, r2);
        hbox.getChildren().add(splitPane2);

Now, you can’t have a single SplitPane with multiple orientations. However, you can quite easily embed one SplitPane inside another to get this effect:

        SplitPane splitPane1 = new SplitPane();
        splitPane1.setOrientation(Orientation.VERTICAL);
        splitPane1.setPrefSize(200, 200);
        final Button l1 = new Button("Top Button");
        final Button r1 = new Button("Bottom Button");
        splitPane1.getItems().addAll(l1, r1);

        SplitPane splitPane2 = new SplitPane();
        splitPane2.setOrientation(Orientation.HORIZONTAL);
        splitPane2.setPrefSize(300, 200);
        final Button c2 = new Button("Center Button");
        final Button r2 = new Button("Right Button");
        splitPane2.getItems().addAll(splitPane1, c2, r2);
        hbox.getChildren().add(splitPane2);

With the code above, you’ll end up with something a little like this:

I hope this helps to introduce you to our brand new SplitPane control, and I look forward to see you using it in your applications soon!

In JavaFX, putting the CheckBox into a mode where it can be indeterminate is quite simple, simply set the allowIndeterminate property to true:

        CheckBox cb = new CheckBox("Indeterminate CheckBox");
        cb.setAllowIndeterminate(true);

You manipulate the state of the check box through the use of two properties: selected and indeterminate. If allowIndeterminate is true, then as the user clicks on the check box, it will cycle through three state combinations:

• selected = true, indeterminate = false
• selected = false, indeterminate = true
• selected = false, indeterminate = false

Here is a full example:

import javafx.application.Application;
import javafx.beans.value.ChangeListener;
import javafx.beans.value.ObservableValue;
import javafx.geometry.Pos;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.CheckBox;
import javafx.scene.control.Label;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class IndeterminateCheckBox extends Application {
    Label label;
    CheckBox cbox;

    @Override public void start(Stage stage) {
        label = new Label();

        cbox = new CheckBox("Indeterminate CheckBox");
        cbox.setIndeterminate(true);
        cbox.setAllowIndeterminate(true);

        ChangeListener<Boolean> listener = new ChangeListener<Boolean>() {
            @Override
            public void changed(ObservableValue<? extends Boolean> prop, Boolean old, Boolean val) {
                updateLabel();
            }
        };

        cbox.selectedProperty().addListener(listener);
        cbox.indeterminateProperty().addListener(listener);
        updateLabel();

        VBox vbox = new VBox(7);
        vbox.setAlignment(Pos.CENTER);
        vbox.getChildren().addAll(label, cbox);
        Scene scene = new Scene(vbox, 400, 400);
        stage.setTitle("Hello CheckBox");
        stage.setScene(scene);
        stage.setVisible(true);
    }

    private void updateLabel() {
        final String txt = cbox.isIndeterminate() ? "The check box is indeterminate" :
                cbox.isSelected() ? "The check box is selected" :
                "The check box is not selected";

        label.setText(txt);
    }

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

So, whenever either the indeterminate or selected property changes, we update the label’s text to match. This is kind of gross though (now that I’ve typed it out), because I have to attach a listener to two different properties. It would be nicer if there were a proper event handler that I could attach to the CheckBox which would be notified whenever indeterminate or selected changed.

I’ve filed a JIRA RT-13992 to track this.

Meanwhile, I can also use the high level binding APIs to do this. Here is an alternative implementation.

import javafx.application.Application;
import javafx.beans.binding.Bindings;
import javafx.beans.value.ChangeListener;
import javafx.beans.value.ObservableValue;
import javafx.geometry.Pos;
import javafx.scene.Group;
import javafx.scene.Scene;
import javafx.scene.control.CheckBox;
import javafx.scene.control.Label;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class IndeterminateCheckBox2 extends Application {
    @Override public void start(Stage stage) {
        CheckBox cbox = new CheckBox("Indeterminate CheckBox");
        cbox.setIndeterminate(true);
        cbox.setAllowIndeterminate(true);

        Label label = new Label();
        label.textProperty().bind(
            Bindings.when(cbox.indeterminateProperty()).
                then("The check box is indeterminate").
                otherwise(
                    Bindings.when(cbox.selectedProperty()).
                        then("The check box is selected").
                        otherwise("The check box is not selected"))
        );

        VBox vbox = new VBox(7);
        vbox.setAlignment(Pos.CENTER);
        vbox.getChildren().addAll(label, cbox);
        Scene scene = new Scene(vbox, 400, 400);
        stage.setTitle("Hello CheckBox");
        stage.setScene(scene);
        stage.setVisible(true);
    }

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

And that’s pretty darn slick, IMHO.