Recently, I wrote about updating an old program that did the Sign Test. Well, I have lots of old programs that could stand a bit of refreshing. Another of the simple ones calculates the confidence interval around the proportion of successes in a series of Bernoulli trials. I wrote about it way back in 2011. The original was written in Java and Swing many years ago. It is still available in a repository on Bitbucket.
In the process of updating some old programs, I had to change the GUI frameworks used. The old programs were written in Java using the Swing GUI framework and the JGoodies Forms and Looks libraries. Nowadays, the official GUI framework for Java is JavaFX. Making the transition from Swing to JavaFX was relatively painless because the programs were so small. However, one of the things I missed from the JGoodies Forms library was the “titled separator”, that is a separator with a label in front of it.
Long ago, I wrote a post about a small program to calculate the probabilities of a sign test. A lot has happened since then. The sign test is still useful to me on occasion, but the application framework used to write the original program is now unsupported. Too, the original program used Java’s Swing framework for the GUI. The new official GUI framework for Java is JavaFX. So I’ve updated the program a bit.
Feeling a bit frustrated today, so I thought I would just vent a bit. I’ve been working on some personal tools. I see some things in other tools that I would like to include in my own. I keep finding that those features that I like are written in JavaScript with that whole mess of an ecosystem. When I look for something similar in Java/JavaFX I find next to nothing.
It’s common knowledge that the JavaFX user interface toolkit is single-threaded. When your JavaFX-based program is doing things that can take some time, you need to run those tasks on a separate thread(s) to keep the interface responsive. Recently, I’ve been working on a program that can spend a lot of time reading and writing to the disk, but at the same time I want to retain the ability for the user to change views of the UI as the work proceeds.
There are many use cases where a mono-spaced (fixed-width) font is useful in programming. Programming editors and creating program listings come to mind. But there doesn’t seem to be a consistent way of obtaining a list of all of the mono-spaced fonts installed in the operating system. Back in the days of Swing, you usually had to grab a list of font families (e.g. Arial, Times New Roman, etc.) from AWT and then create a BufferedImage to print the font to and check layout widths.
Recently, I answered a question on StackOverflow related to executing a long-running task in the background of a JavaFX application while updating the UI on the progress of that task. I have found myself coming back to that solution several times now.
For a little while now, I’ve been working on an application that manages a list of documents, providing multiple views that the user can edit.
The application looks something like this:
The document manager main screen
The user selects the document they wish to view or edit by selecting it from the large TableView in the middle of the window. The area on the right provides controls to view and edit details. (The area on the left is for filtering the documents displayed in the central table.)
Based on some early advice, I had watchers on the focus property of the fields that could be edited. When a control lost focus, any changes were written to the database. The user didn’t have to do anything to save their work. It just happened.
This worked with Java 7 and JavaFX 2. After the switch to Java 8 and JavaFX 8, things were not quite the same. If a user was making a change somewhere and then selected another document without moving to another editing view, the data was lost. The focus change notification did not arrive before the new document was selected in the table (repopulating the editing control before the data was saved.)
I like to use programs that can remember what I was doing the last time I was working with them. They should restore the window just as I had it, remember which file(s) I was working with, what preferences I had selected, and so on. Naturally, I want the programs I write to be just as considerate of the user.
For some time, I’ve been fretting over the best way to do this in a Clojure program. Should I provide wrappers around the Java Preferences API? Some other mechanism? Turns out I should just embrace simplicity.
Just a short rant about JavaFX because I’m pissed about it at the moment. I enjoy using it for the most part but it sometimes throws up surprising obstacles in otherwise routine work. The latest for me was an unexpected lack of a spinner control. There are alternatives in some open source projects, but, really? No spinners built in? This is almost as gob-smacking weird as the lack of dialogs. (Ok, there are some dialogs, like for opening/saving files, but not much in the way of user-programmable dialogs built in.
A couple days ago, I posted a little snippet showing how to load and font from a list of preferred fonts using Clojure and JavaFX. Well, I’ve extended the demo a bit to show how to load both fonts installed on the OS and fonts from a resource file. Here’s the new snippet. (ns clojure_font_loading.core (:gen-class :extends javafx.application.Application) (:import [javafx.application Application] [javafx.event EventHandler] [javafx.
Just wanted to pass along a little snippet I have found myself using fairly frequently. CSS has the ability to specify the appropriate font to use in displaying a document. It handles the tag in such a way that it can gracefully degrade from a “preferred” font through a series of less ideal typefaces depending on what’s available on the machine doing the display. That’s a handy facility to have, even on Windows, which can have different fonts available depending on the version of Windows and what software has been installed.
Most programs written for graphical user interfaces still provide a way to operate with the keyboard, requiring minimal mouse usage. The thought is that expert users will want to speed through their work keeping their fingers on the keyboard rather than devote an entire hands worth of fingers to controlling the mouse. I’ve been learning JavaFX, the eventual replacement for the Swing UI framework on Java, and wanted to explore how shortcut functionality had changed.
I’ve been experimenting with adding keyboard accelerators to some of the Clojure programs I’ve written with JavaFX-based user interfaces. As part of that investigation, I tried to translate the Java program here (Broken Link) to Clojure. The program just puts up a window with a menu bar containing only a “File” menu which itself contains one item, “Exit”. Most programs provide a keyboard shortcut or accelerator to close the program with a Ctrl-X (on Windows). Figuring out how to add that functionality was a bit of an issue for me.
Recently, I have been experimenting with JavaFX in Clojure. Initially, in one of my experiments, I wanted to learn how to re-size a game-board interface as it’s containing window was re-sized. In the past I’ve had medical device interfaces that draw a representation of a physical device and these drawings must re-size as their window is re-sized. The initial experiment was with a simple interface for Tic-Tac-Toe. Since I had such a nice interface, I thought, why not program the complete game.
I’ve been having a lot of fun learning JavaFX, even after many years of using the Java Swing framework.
One thing about JavaFX that I still don’t understand is the lack of built-in support for dialogs. Well, that shortcoming has annoyed enough people that there are several efforts underway to provide dialog functionality. One of those is part of the JFXtras project, MonologFX.
Since JavaFX is the future of the user interface for Java, I’ve started trying to learn it. Since I’m also learning Clojure, I’m doing the work in that language. One of the things I’ve been looking into is how the interface responds to resizing. If you have all of your controls in a nice layout, that is usually taken care of for you. But how do you handle things if the interface is not made up of standard components, something like a graphical game interface for example?