Enzo’s simple gauge in JFXtras

Gerrit Grunwald is an enspiring internet of things (IoT) evangelist and his JavaFX library ‘Enzo’ contains many visually attractive controls, well suited for IoT but also many other JavaFX applications. Gerrit used to be an active contributor to JFXtras, but he decided to move his work to his Enzo library. Why? Because the scope of JFXtras did not fit his needs.

As an IoT evangelist he develops many JavaFX controls for his demos, and he wants to get results fast; there is always that next conference in a few days.  JFXtras on the other hand tries to uphold a certain quality by a.o. requiring tests to prevent regression. This is not something a roaming evangelist wants to invest his time in. So we end up with an interesting situation; great but risky controls! Examples of this are all the gauges that are part of JFXtras-labs 2.x: they were never ported to 8.x and thus all their users have a problem there. This of course is the risk of using anything from JFXtras-labs, it is after all JFXtras’ playground, with no guarantee what-so-ever.

So what now? Great controls but too risky to touch? For Enzo that may be the case, as Gerrit states on his blog; “Please keep in mind that all controls in that library are made for my personal demos and are not production ready”. However, Gerrit and I have an agreement that I’m allowed to become ‘inspired’ by (aka blatantly copy) his demos. This already happened with CornerMenu, which was inspired by one of Gerrit demo’s and spawned CircularPane and CirclePopupMenu. The next inspiration Gerrit gave me was his SimpleGauge.

metroArcGauge

The control you see above is from  JFXtras and is known as SimpleMetroArcGauge and it (at the time of writing this) is part of JFXtras-labs. Currently it is in the process of fleshing out the API, which will be much more minimalistic than SimpleGauge, relying more on stylesheets. And also the concept of a single LinearGauge superclass is tried. After all, there is more to a good gauge than just a beautiful face.

When the gauge is finished, tests are written, and a sample is added to the samples, the gauge will move from labs to a new “gauge” module of JFXtras.

So there you have the explanation why suddenly Enzo controls start appearing in JFXtras.

Advertisements

7 thoughts on “Enzo’s simple gauge in JFXtras

  1. It’s not in JFXtras and that’s good. Please stop from putting stuff into JFXtras. It shouldn’t become the next SwingX. I rather prefer to have separate components (and sources) than some big jar file that contains interdependent components. It’s much more of a risk than having smaller maintainable parts.

  2. Please have a look at how JFXtras is setup; there are several separate jars; controls, agenda, fxml, …, and the gauges will go in a separate jar as well (as mentioned in the one-but-last paragraph).

  3. I’ve seen it, that’s why I don’t want it. Example: I’d like to create only a radial menu. Usually you have to tweak it a bit. With the Enzo library I take the radialmenu package and I’m done with it. Easy to tweak the source code. With a library with interwoven bits and pieces it’s not so easy. Or e. g. the simple gauge on this website. Just use the gauge package from the Enzo library, nothing else. Easy to include, easy to use. I prefer to have the project as minimal as possible rather than having to rely on lots of libraries.

    1. Yes. Well, that’s a conversation I have been having with Gerrit as well. Suppose one were to create a single jar for each component, like you suggest, then in time the project could end up with over 100 artifacts on Maven central. Right now we would have a ListSpinner, CalendarPicker, CalendarPickerTextField, LocalDatePicker, LocalDatePickerTextField, etc. Such a high level of fragmentation will make people state exactly the opposite of what you do: I do not want all those dependencies in my pom. And consider reuse; CalendarPicker uses ListSpinner, LocalDatePicker uses CalendarPicker, … FXML support for each component uses the component; the tree quickly becomes large.

      In my opinion projects usually don’t use a single component out of a group, unless it is something very specific like Agenda (that is why it is in a separate jar). If people use a gauge, changes are high they will use a second as well. So I’m are aiming at a middle ground; grouped jars.

      But hey, if it is not for you, it is not for you. You are welcome to use Gerrit’s great Enzo library.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s