Yuck, ‘CheckBoxTreeView’ – what a mouthful. Anywho – I was just looking at a very interesting JavaFX session slidedeck from Jazoon presented by AdNovum Informatik AG titled ‘JavaFX – The Condemned Live Longer‘. It is a great slide deck as they are a company that have invested a lot of time researching the available RIA technologies, and they are pretty upfront with what they like and don’t like in JavaFX, and what their developer experience has been.
The MenuButton and SplitMenuButton controls
We recently discussed the new preview Menu control that is part of JavaFX 1.3. Another part of this release is a number of controls that make use of menus internally, and this post talks about two new preview controls that do just this: MenuButton and SplitMenuButton. (more…)
Important Note: Menus (and related classes) are ‘preview’ API in JavaFX 1.3, which means that the API may (and most probably will) change in future releases. However, you’re welcome to make use of these preview controls in 1.3. Read on to learn how.
Up until the release of JavaFX 1.3 it was not possible to build proper menus that ‘popped’ out of the Stage, as one expects a menu to do. It was not until we were able to expose other functionality internally that creating proper menus became possible. As already warned, in JavaFX 1.3 menus are preview controls whilst we firm them up and get feedback from the community. In this post I wanted to outline the API, and what options you have for styling them using nothing more than CSS.
In JavaFX 1.3 a lot of work has gone into ListView, and extracting out the base virtualization engine (the secret sauce to high performance lists) such that it is able to be used in controls such as TreeView and TableView. At the same time we wanted to make it really easy for developers to customize what is shown in each ListView row. What we’ve ended up doing is creating the concept of a cell, which at any point in time represents at most one item in your ListView, and it is through the cell that you have total freedom about how to display your data. Finally, as noted, we’ve expanded this concept to also be used in exactly the same way in TreeView (which is a preview in JavaFX 1.3), and it is likely to also underpin any future TableView control.
One of the really neat things about the JavaFX ListView control is the Cell API, and the ability to have dynamically variable row heights, without sacrificing performance or scalability. To accomplish this, we’ll write a custom Cell factory which will create a Cell who’s size depends on some state.
To recap briefly, to remain scalable and fast, the ListView reuses Cells for rendering each row in the ListView. Because it reuses Cells, each Cell needs to be designed so that it does the right thing no matter what row it is asked to represent — even empty rows which are used only for filling out a ListView and not for actually holding valid data. (more…)
We have not yet provided a SplitView Control in JavaFX (and it is not in the plan for 1.3). However, the main reason is that it is relatively simple to write one from scratch so we’re focusing on some of the harder things (like TreeViews). I was asked recently how to go about writing a SplitView in JavaFX, so I decided to write a very short blog post with sample code from a demo I wrote for this past Devoxx. (more…)
In a couple hours Jasper and I will be presenting a talk titled “Enterprising JavaFX” at Devoxx. The main purpose of the talk is to describe how to use JavaFX for writing enterprise application content. Here’s a quick teaser screenshot of one of the apps we’re going to describe:
Jira Dashboard Application
We’ll be writing some additional blog posts over the next few weeks describing various tips n’ tricks as to how we used web services in this app, how we wrote the custom list cells, and so forth.
Create an application in JavaFX that exemplifies the appearance and behavior of a next-generation enterprise RIA (rich internet application)
See the official announcement for more details on the rules etc. Announcing the JavaFXpert RIA Exemplar Challenge
I will be judging the entries for their visual design with the help of fellow graphics judge Romain Guy. To help all the designers entering here are a couple of the original designs for the Caspian theme along with links to the photoshop files they were created with. This way you can see the how all the all the controls visuals are contracted using vector shapes and layer effects.
Download Controls Mockup.PSD.ZIP
I also thought maybe some links to sites with good articles on design might be helpful. Most of these are associated with Web Design rather than Application User Interface Design but there is a large amount of cross over and I have not found any good sites on Application User Interface myself.
Here are a few links for inspiration:
When you have a lot of data to display in a Control such as a ListView, you need some way of virtualizing the Nodes created and used. For example, if you have 10 million data items, you don’t want to create 10 million Nodes. So you create enough Nodes to fill the display dynamically. Because of our heritage in Swing, we know how critical this is for real apps. I got an optimization issue reported this morning on “UI Virtualization”. (more…)
One bug which gets filed over and over again is related to the idea of whether Controls should resize themselves when their content / settings change. The earliest such bug was with TextBox. TextBox has a columns property which, like in Swing, can be used to hint how many “columns” of text should be displayable in the Control by default. The TextBox skin implementation uses this information in conjunction with the font and other settings to determine the preferred width of the TextBox.
When a Control is created, if you do not explicitly specify its width or height, then it is sized according to its preferred width and/or preferred height. If you use a Control within a layout Container (which was anticipated as being the common case) then you (almost) never explicitly manage its dimensions – you leave that chore to the Container. However, if you do not use a Control within a layout Container (which turns out seems to happen quite a bit) then it does not explicitly resize itself whenever, say, columns changes.
Take Button as another example. If you create a Button with the text “OK” and do not specify a width or height, then the Button will be initialized to its preferred size. However, if you then change the text of the Button to be “Cancel”, then the Button will not automatically resize, and will therefore not be wide enough to display all the text and you’ll see something like “C…”, if you’re lucky. Or “…” if you’re not.
I’ve filed RFE http://javafx-jira.kenai.com/browse/RT-5122 targeted at the next release. The idea here is to have an “autoSize” variable on Control which will be true by default. Problem solved, right? Well, not quite. The problem with autoSize is that when placed in a Container, the Control should not attempt to resize itself. So we’ll end up with code essentially like this:
if (autoSize and not (parent instanceof Container)) {
// resize the width because the text has changed, or whatnot
}
Not very pretty. But given the options and the amount of frustration it is causing developers, I’m willing to accept that bit of nastiness. What do you think? Have any good ideas? Leave comments & votes on the bug if you like!