# DashboardFx: a JavaFX dashboard styled with CSS

> DashboardFx is a JavaFX project that applies CSS styling to build a dashboard-style desktop interface, with the components, the tutorials and the supporting libraries in one place, built on Gradle 8.13 and Java and JavaFX 23. It suits a Java developer who wants a desktop dashboard that does not look like the default JavaFX theme, and it is a single-author project on an alpha branch.

**gleidsonmt/DashboardFx** — JavaFx Dashboard, see what happens when you combine the power of css with Java to create modern components.

- Repository: https://github.com/gleidsonmt/DashboardFx
- Website: https://gleidsonmt.github.io/
- Stars: 536 · Forks: 155
- Language: Java
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/gleidsonmt-dashboardfx

## What the project is, in the author's words

DashboardFx is described as a JavaFX dashboard, and the readme opens with an unusual framing: Hi guys, I'm back, with more, after these years I looked for some things that can be really good-looking to build, and I want to share it.

That sentence tells you a lot about the project. It is a personal demonstration of what the author found while looking for good-looking JavaFX, and it is being shared as an example of how components in JavaFX can be worked to align with a good design, with the parenthetical I try attached to that last claim.

Two things distinguish it from a component gallery. The first is the tutorials: the readme says that this time the author used more time to create more tutorials and unify libs, and that when the app is running you can have a tutorial about creating these things shown inside it. A tutorial rendered by the application it is demonstrating is a real design idea, and it is the kind of thing a designer wants to see working rather than read about.

The second is the range of the repository contents. The top-level listing holds build.gradle.kts alongside an older buildOld.gradle, a glad directory for JavaFX native library bindings, a presentation directory, a src/ directory, a vendor/ directory with jars, gradle/ and the wrapper scripts, and project.properties. There are also screenshots/, screen.png, PLANS.md, ENHANCEMENTS.md, HISTORY.md, CONTRIBUTING.md and the LICENSE.txt. The two build files side by side suggest a project mid-migration, and PLANS.md and ENHANCEMENTS.md are the author's own record of what comes next.

The primary language is Java, the topics list a spread of javafx, javafx-application, javafx-components, javafx-desktop-apps, javafx-frameworks, javafx-gui, javafx-library and javafx-project, and the default branch is alpha rather than main.

## The environment, and the vendored jars

The environment section is short and specific, and the two details that matter are the toolchain versions and the vendor directory.

The author used Gradle 8.13 with a preference for the wrapper, and Java and JavaFX 23 or newer on Windows. The project links the official JavaFX site and its Getting Started tutorial, which suggests the audience is expected to already be comfortable with JavaFX rather than to be introduced to it here.

Then there is the line about the jars: You'll find the jars in the folder called vendor, and all libs are included in build.gradle. So the third-party libraries are committed to the repository rather than resolved by a dependency manager.

That is a significant design decision for a Gradle project, and it has consequences in both directions. It means a clone of the repository builds without resolving anything from Maven Central, which is good for reproducibility and for offline builds, and it means the jars are pinned to whatever versions the author chose at the time. The build file then references those local jars rather than coordinates. It also means the repository carries a large amount of binary content, and that a security update to any of those libraries requires the author to replace the jar rather than a version bump.

The vendor directory is not the only place binaries appear. The glad directory is the standard tool for generating JavaFX native library bindings, and the fact that it is checked in alongside the jars suggests the native libraries for several platforms are committed too. The build.gradle.kts and the buildOld.gradle suggest a Kotlin DSL migration in progress.

The default branch being alpha is the third data point. There is no main branch and no tagged release, so what you get from a clone is whatever state that branch was in.

## Building and running it

The clone command is given with the recursive flag, because there are submodules:

```bash
git clone --recursive https://github.com/gleidsonmt/DashboardFx.git
```

The readme explains why: this command will clone the project and all submodules. Given the .gitmodules file at the repository root, there is at least one dependency that lives outside the main repository.

The build is three Gradle wrapper invocations, run in order:

```bash
.\gradlew init
.\gradlew build
.\gradlew run
```

The readme describes them one by one. First prepares the project, second builds the project, third runs the project. The commands are written with a backslash prefix, which is the Windows command prompt convention, and that matches the note that the setup was done on Windows.

The author's own summary is characteristically informal: Just build and run, there's no trick, only use Gradle to build and run in your ide. The IDE mentioned in the environment section is IntelliJ, given the reference to the jpackage instructions later.

For packaging, the readme recommends jpackage to create the jar and the .exe, and it flags the requirement with a note that generating the .exe needs the wix toolset, linked from the IntelliJ page or from wixtoolset.org. In IntelliJ or Visual Studio, with the IDE prepared to use JavaFX, the author says it is simple: open the gradle tab and run the build command after jpackage.

One warning there is worth taking seriously. The readme says not to use any library like scenicView or cssfx when you build a jpackage, because those are only to test the design, and the result may not be what you expect or may crash the application. Those tools are for previewing CSS in a designer, and shipping one inside a packaged build is a mistake that the author has clearly seen before.

## Where DashboardFx is the wrong choice

The first limitation is the maturity. The default branch is alpha, the repository publishes no GitHub releases, and there is no version to pin. For a library you would import, that is a hard stop, and for an application you would fork, it means you are starting from a moving snapshot with no changelog discipline, although the presence of HISTORY.md and ENHANCEMENTS.md shows the author does keep some record.

The second is the single-author nature of it. The readme asks for contributors with a fork, a branch, a commit and a pull request, and then says it in a more direct way: I really need more friends, with an email address. That is a friendly invitation, but it also tells you what to expect. Review is going to be informal, the roadmap is PLANS.md written by one person, and the long-term direction depends on one person's continued interest.

The third is the vendored jars as a maintenance model. Committing library binaries means the project's dependencies are frozen at the versions in vendor/, with no automated update path. When a library in that set has a security advisory, nothing in the build surfaces it, and the fix is a manual replacement of a binary file. For a demonstration project that is a reasonable shortcut, and for anything you intend to maintain it is a liability.

The fourth is the dual build system. build.gradle.kts and buildOld.gradle both exist in the root, and settings.gradle sits alongside. Two build files usually means a migration in progress, and the readme's instructions only cover the wrapper. If you take this as a starting point for real work, you will spend time working out which build file is authoritative.

The fifth is that this is a demonstration rather than a framework. The readme describes it as an example of components aligned to a design, with the author sharing what he found. There is no published API contract, no compatibility promise, and no documentation beyond the readme and the in-application tutorial. If you want reusable styled JavaFX components as a dependency, you would be treating a single author's showcase as a library, which is a different proposition from what the repository presents.

## Conclusion

DashboardFx fits a Java developer building a desktop dashboard who wants the CSS styling approach applied to a working set of JavaFX components and, unusually, a tutorial shown inside the running application, since the readme states that when the app is running you get a tutorial about creating these things shown inside it. It is the wrong choice for a production desktop product, because the default branch is named alpha, the repository publishes no releases, and the author describes it as a project for sharing what he looked for and built. Before adopting it, read ENHANCEMENTS.md and PLANS.md for the direction of travel, check that the vendored jars match your own dependency set, and note that the last push was on 2026-06-30 with the project recorded under a GPL-3.0 licence.

## FAQ

### What is DashboardFx?

It is a JavaFX dashboard project that demonstrates how JavaFX components can be styled with CSS to produce a modern look, with tutorials and supporting libraries unified in one repository and a tutorial about creating the components shown inside the running application.

### How do I build and run DashboardFx?

Clone the repository with the recursive flag so submodules come too, then run the Gradle wrapper commands in order: .\gradlew init to prepare the project, .\gradlew build to build it, and .\gradlew run to run it. The author used Gradle 8.13 with the wrapper and Java and JavaFX 23 or newer on Windows.

### Where are DashboardFx's dependencies kept?

The jars are committed in the vendor/ folder and all the libs are included in build.gradle, rather than resolved from a dependency repository. The repository also carries a glad directory for the JavaFX native library bindings.

### How do you package DashboardFx into an executable?

The readme recommends jpackage to create the jar and the .exe, which needs the wix toolset installed. In IntelliJ or Visual Studio you open the gradle tab and run the build command after jpackage, and the readme warns against including libraries such as scenicView or cssfx, which are only for testing the design.

### What licence is DashboardFx released under?

GPL-3.0. The readme says the project is under license and points to the LICENSE.txt file for details, and the repository records the same licence identifier. The last push was on 2026-06-30, the default branch is named alpha, and the repository publishes no GitHub releases.

## Sources

- [gleidsonmt/DashboardFx on GitHub](https://github.com/gleidsonmt/DashboardFx)
- [Issues](https://github.com/gleidsonmt/DashboardFx/issues)
- [License: GPL-3.0](https://github.com/gleidsonmt/DashboardFx/blob/alpha/LICENSE)
- [Project website](https://gleidsonmt.github.io/)
- [README](https://github.com/gleidsonmt/DashboardFx/blob/alpha/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gleidsonmt-dashboardfx