JavaFX Archives - Page 14 of 25

Dec, 16 2013

Skinning in Java8 (JavaFX8)

There has been some changes in JavaFX8 regarding skinning, the most relevants of which are the new CSS API that allows you to create new CSS properties and pseudo-classes for your controls and the Skin class which has become public.

Using CSS you can change a lot of the appearance of a control, but there is only so much you can achieve with CSS and this is where the Skin class comes in. A quick look at the architecture of controls from “UI Controls Architecture”:

Controls follow the classic MVC design pattern. The Control is the “model”. It contains both the state and the functions which manipulate that state. The Control class itself does not know how it is rendered or what the user interaction is. These tasks are delegated to the Skin (“view”), which may internally separate out the view and controller functionality into separate classes, although at present there is no public API for the “controller” aspect.

Like was mentioned there is still some aspects of Skinning that are not yet public API and that is the Behavior class, however, with the current state of things, you can already do a lot.

Since Java8 is not in G.A. status (full finished version) yet, there is still a considerable lack of documentation regarding the API, which brings me to my latest post on JMetro, at that time I was mistakenly under the impression that you had to extend a control in order to change its reference to the skin class, that’s why I created the ErasableTextField. However, as I later learned, you can change the skin class of a control just through CSS, like this:

.text-field{
    -fx-skin: "jfxtras.styles.jmetro8.MetroTextFieldSkin";
}

The “text-field” style class is assigned to TextField, so when the “-fx-skin” CSS property value is changed the reference to the skin class that is to be used with this control changes. So the ErasableTextField class is no longer necessary and has been removed from JMetro.

I find this design very interesting! As you can see the Skins are completely decoupled from the controls, all you have to do is assign a stylesheet to a scene without touching any of the code in your app and the look and feel of your application can change radically – like for instance JMetro Textfield skin adds a clear button that shows up whenever there is text inside:

JMetro adds a clear button to TextField

Dec, 13 2013

DateAxis and XYBarChart update

Just the other day Gerrit Grunwald (@hansolo_) tweeted he made a DateAxis which supports JSR310 (date/time) api, and which is based on my work and also on Christian Schudt and Diego Cirujano-Cuesta work (they created a DateAxis which accepts DateTime). He later added that he would eventually create a blog post about it if he had time (you should stay tuned his posts are usually high quality). This reminded me that a blog post about my DateAxis and XYBarChart is long overdue since I’ve made a lot of changes since my last posts on the subject. Besides the changes I also wanted to explain my implementation of the DateAxis and why I’m sticking with the design (code design not artistic design) choices I’ve made.

Design decisions while creating DateAxis

While creating DateAxis I had two choices, either extend from Axis or from ValueAxis. Extending from Axis would allow me to accept DateTime or the new date formats from JSR310, while extending from ValueAxis would guarantee the presence of methods like setLowerBound and setUpperBound which would allow a user to filter or zoom in on specific dates, a fairly common use case, but would mean programmers would first need to convert the date to a number before adding it to the chart. Of course you can add filtering methods yourself while extending from Axis but a component that does zooming on charts and is expecting a ValueAxis (which guarantees setUpperBound and setLowerBound) wouldn’t work with that implementation.

Even though at first I was thinking that extending from Axis would be better, I’m now more convinced that the current solution – extending from ValueAxis, is a better one, for the reasons expressed earlier, and the draw back of having to convert the date to a number isn’t such a big thing.

~~I think it would be best if the JavaFX charts API would allow one to separate the position of a value in an axis from the value itself~~ I think it would be best for setLowerBound and setUpperBound to be mandatory methods on Axis, but has things are right now you have to take in consideration the two drawbacks mentioned earlier before starting to implement a new axis.

Changes made to DateAxis and XYBarChart

I’m afraid I’ve probably forgotten about most of the changes I’ve made, anyway here’s what I recall:

DateAxis

After changing range (by zooming in for instance) the tick marks interval stayed the same. Now they are recalculated.
Added a bigger set of tick ranges to accommodate a higher range of dates.

XYBarChart (this previous post explains what this is)

On some occasions depending on the data you add to the chart, it may not render any bars even though there is data to be displayed. This is a bug that exists in javafx BarChart and was passed on to this chart since there was some copying of code.

Today, I also added one more enhancement to the DateAxis which was on the pipeline of changes I wanted to make. Basically the format of the dates will change depending on the range of values that is being shown: for instance, if each tick mark represents more than a month than only the month and year of that tick mark is shown otherwise the day, month and year is displayed. A similar thing happens if the range of tick marks is bigger than one year, in that case only the corresponding year is shown. The following pictures show the before and after this change.

XYBarChart with a DateAxis – before change

XYBarChart with a DateAxis – after change

This is just a small detail that makes for an easier scanning of the chart by the user.

If you want to join me, in adding more features to the charts API, you are welcome. My eventual objective would be for this to be integrated in the JavaFX API (at least the DateAxis) although I don’t know if that would be possible.

Dec, 8 2013

Metro style Text Box control for java (JMetro)

The Metro Text Box control is the usual input text field from which developers can get text input from users. This control has a particular trait usually present in control library designed to be used through touch: whenever the user enters text a clear button appears on the right most position of the control.

Windows 8 Text input control

This particular feature isn’t available in the text input control from the JavaFX library, so the use of CSS won’t be enough to achieve a “metro” style.

For this reason I’ve created a new control: ErasableTextField (Yes, I know, not the best choice of a name for a control 🙂 ), which extends from TextField and adds this missing feature: a button which appears inside the text input control to clear it whenever there is text inside. Then through the usual use of CSS I style the control to make it look like the Windows 8 Text Box.

JMetro TextBox Dark theme - mouse pressed

JMetro Dark Theme – mouse pressed

JMetro Dark Theme

JMetro TextBox Light Theme - text selected

JMetro Light Theme – text highlighted

JMetro TextBox Light Theme

Dec, 1 2013

Metro style Rating control for java (JMetro)

The Rating control is one of Windows first class citizens, it’s available in its control library, it allows a user to rate something from 0 to an x value. Given the importance of today’s social interaction it’s no wonder it has gained the status of a library control.

ControlsFX is a third party library of controls for JavaFX, it complements the standard library with some more useful controls and functionality which are not available straight from JavaFX’s standard library. One of the controls present is the Rating control which I opportunely took the chance to use and style the metro way through CSS.

The Rating control (default style)

In its default style, this control uses raster image files. One for the “selected” state:

and one for the “unselected” state:

Using this CSS code for the “unselected” state:

.rating > .container > .button {
  -fx-background-image: url("unselected-star.png");
}

And this for the “selected” state:

.rating > .container > .button.strong {
  -fx-background-image: url("selected-star.png");
}

“.strong” is the style class given to “selected” star buttons.

For JMetro I wanted to use vector based images instead of raster ones. To that effect I used the CSS property: “-fx-shape” and set the “-fx-background-image” to null which is the same as removing it.

Rating control – Dark theme (mouse pressed)

Rating Control – Dark theme

Rating control – Light theme (mouse pressed)

Rating control – Light theme

Advantages of using vector based images:

You can make them as big as you want without losing image quality
Fill color, stroke color, etc can be tweaked through CSS
It occupies less space

By this, I’m not saying that vector based images should be used every time, there are certainly use cases where raster based ones are more convenient, specially at lower sizes.

In conclusion, you can do some really powerful stuff this way using only JavaFX CSS code. You can either rely on the usage of raster based images or vector based ones.