scalafx | ScalaFX simplifies creation of JavaFX-based user interfaces

I actually get two errors when I execute sbt run on your code, and I do not get a deprecation error:

Astonishingly, that doesn't seem to be supported.

The property that changes during the expand/collapse phase is the content's height: so a hack around might be to listen to it and start editing when fully expanded (which is a bit hacky in itself, could change due to layout constraints as well).

The example below simply initializes the fully expanded height after showing, listens to content's height property and starts editing when it reaches the fully expanded height.

The code:

With the problem of wrong highlighting out of the way, the solution is simple. Just for reference, here is the above code modified with all the asked Options for TableView:

Well, you can design your application as abstract e.g.

A JAR is just like a zip of classes, each class is the one that you can check with javap to see which JDK version they need by looking at the value of the "major version" field; see this.

If you want to ensure the classes are compiled to a specific Java version, you can use the release & target scalac options.

Like this:

One of the issues here is that List() doesn't work the way you appear to think it does.

Firstly, the :+ operator does indeed append an element to the list (which is a slow operation, since the entire list must be copied each time; you should prefer prepending instead). However, this operator returns a new list containing the appended element, but since you don't store the result, it is thrown away. (Scala Lists are immutable elements, and cannot be modified, so List operators return new List instances instead. This is actually highly desirable for Scala's Functional Programming paradigm.)

Secondly, Lists are not observable. Even if you could modify lists by adding elements to it, there would be no way for topMenuBar.menus, menuFile.items or menuEdit.items to know about the additions to their lists. So, all you're doing is copying empty lists to each element.

There are a few alternatives, one which involves initializing List instances before assigning their contents to the GUI, and the other which uses an ObservableBuffer instead of a List. (If using an ObservableBuffer, you would have to bind it to the associated property, using the ScalaFX <== operator; there are examples in the ScalaFX demo models. For further background, ObservableBuffer is the ScalaFX equivalent of JavaFX's ObservableList.) I'd prefer the former, because observable elements should typically only be used if you need to dynamically modify them during your program's execution.

Here's the first approach, which populates the lists first, then assigns them to the associated GUI element:

Most JavaFX example code conflates the main method with the Application subclass, and in many cases even does the UI layout, etc., in the same class. There's not necessarily a reason to do this, and in the latter case it's not a particularly good design.

Assuming you separate concerns appropriately in your UI code, you might have a class like

The problem here concerns JavaFX (and hence, ScalaFX) initialization.

Initializing JavaFX is a complex business. (Indeed, I only recently learned that it was even more complicated than I originally believed it to be. Refer to this recent answer here on StackOverflow for further background. Fortunately, your problem is a little easier to resolve.)

ScalaFX simplifies JavaFX initialization greatly, but requires that the JFXApp trait be used as part of the definition of an object.

JFXApp contains a main method, which must be the starting point of your application; it is this method that takes care of the complexities of initializing JavaFX for you.

In your example, you have your Driver object extend scala.App, and so it is App's (and hence, Driver's) main method that becomes the starting point of your own application. This is fine for a regular command line interface (CLI) application, but it cannot be used with ScalaFX/JavaFX applications without a great deal of additional complexity.

In your code, JFXApp's main method never executes, because, as it is defined as a class member, it is not the main method of a Scala object, and so is not a candidate for automatic execution by the JVM. You do call it manually from your Graph.generateChart() method, but that method itself is not called until after you try to get the title of the scene, hence the NPE as the stage has not yet been initialized.

What if you put the graph.generateChart(args) call before the println(graph.getTitle()) statement? Will that fix it? Sadly, no.

Here's why...

JFXApp also performs one other bit of magic: it executes the construction code for its object (and for any other classes extended by that object, but not for extended traits) on the JavaFX Application Thread (JAT). This is important: only code that executes on the JAT can interact directly with JavaFX (even if through ScalaFX). If you attempt to perform JavaFX operations on any other thread, including the application's main thread, then you will get exceptions.

(This magic relies on a deprecated Scala trait, scala.DelayedInit, which has been removed from the libraries for Scala 3.0, aka Dotty, so a different mechanism will be required in the future. However, it's worth reading the documentation for that trait for further background.)

So, when Driver's construction code calls graph.generateChart(args), it causes JavaFX to be initialized, starts the JAT, and executes Graph's construction code upon it. However, by the time Driver's constructor calls println(graph.getTitle()), which is still executing on the main thread, there are two problems:

1. Graph's construction code may, or may not, have been executed, as it is being executed on a different thread. (This problem is called a race condition, because there's a race between the main thread trying to call println(graph.getTitle()), and the JAT trying to initialize the graph instance.) You may win the race on some occasions, but you're going to lose quite often, too.
2. You're trying to interact with JavaFX from the main thread, instead of from the JAT.

Here is the recommended approach for your application to work:

Personally I would assume that all Listeners and Handlers are by definition impure objects from outside of our pure world, so if I wanted to keep things pure, I would make them send commands as values through some IO.