# Workbench: a code playground for GTK and GNOME technologies

> Workbench is a GPL-3.0 GNOME application that lets you write a GTK interface in JavaScript, Python, Vala or Rust and see it render as you type, backed by a library of more than a hundred examples. It suits learners and anyone sketching a GTK user interface before committing to a real project, and it is a Flatpak only application with only the Flathub build supported.

**sonnyp/Workbench** — Code playground for GNOME 🛠️

- Repository: https://github.com/sonnyp/Workbench
- Website: https://apps.gnome.org/Workbench
- Stars: 850 · Forks: 91
- Language: JavaScript
- License: GPL-3.0
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/sonnyp-workbench

## A GTK interface you can see before you ship it

Workbench lets you experiment with GNOME technologies, whether you are tinkering for the first time or building and testing a GTK user interface.

The pitch is a live loop. You write code, the interface appears next to the editor, and you change the code and see the result again. For GTK, that loop matters more than for most toolkits, because GTK user interfaces are declarative, verbose, and slow to learn from documentation alone. A button that is three lines of XML in a .ui file is much easier to grasp when you can watch it appear.

The features list is what you would expect from an editor built around that loop. Live GTK and CSS preview. A library of more than a hundred examples. Support for JavaScript, Rust, Python and Vala. Declarative user interface syntax. Autosave, sessions and projects. Code diagnostics, completion and a formatter. Terminal output.

The audience is broad in one direction and narrow in another. Broad, because the testimonials in the README come from people learning GTK, from students to established developers. Narrow, because this is a GNOME desktop application, not a general editor, and the technologies it targets are GTK, libadwaita and Blueprint.

The repository is JavaScript at the top level, which fits a GJS based GNOME application, and the topic list names the pieces: gjs, libadwaita, gtk4, gtk-rs, pygobject, vala and rust, alongside blueprint and flatpak.

## Blueprint and CSS cover the declarative half of the stack

The language support table in the README lists six things, and two of them are not programming languages at all: Blueprint and CSS.

Blueprint is the declarative user interface syntax that Workbench supports, and it is the modern replacement for hand written GTK XML in the GNOME world. CSS handles the styling side, with a separate CSS language server in the credits list alongside the GTK one.

The table records formatter and linter support for each entry, and both Blueprint and CSS have a formatter. The JavaScript, Python, Vala and Rust rows have both a formatter and a linter, and the four language rows additionally carry a count of library demos, with Blueprint and CSS left empty in that column.

That split is the clearest statement of the design. The programming language is the part you swap freely, while the interface definition and the styling are shared across all of them, which is why the same Blueprint markup works whether the logic behind it is in JavaScript, Python, Vala or Rust.

It also explains a piece of the tooling. The repository has a separate language server configuration per ecosystem, and a formatter invocation per file type, because a project that hosts four languages has to pick a tool for each of them rather than one setting for everything.

## The example library is the part that carries the learning

The demo counts in the README are more revealing than the headline of a hundred plus examples.

JavaScript has 103 library demos, Python has 98, Vala has 92, and Rust has 52. The footnote records when those numbers were taken, as of 2024-06-16, and how they were counted, with a command using scc over the demos source directory.

The counts tell you where the project's attention has gone. JavaScript, the language the application itself is written in, has the deepest library, and Vala, the traditional GNOME language, is close behind. Rust is lower, which is consistent with the project still working through its gtk-rs support.

For a learner, the practical question is whether there is an example that looks like the widget you are trying to build. With a hundred entries for JavaScript and Python, the chance of finding a close match is high. With fifty two for Rust, it is lower, and you will be more likely to adapt a GTK example by hand.

One licensing detail applies to all of them. Everything under src/Library/demos is in the public domain under the terms of CC0 1.0, while the rest of the project is GPLv3. So the examples themselves can be reused in your own project without the copyleft obligation attaching to them, which is a deliberate and useful split.

## Flatpak only, and only the Flathub build

The README states it in one line: Workbench is made possible by Flatpak, and only Flathub Workbench is supported.

That is a hard constraint rather than a preference, and it has two consequences. First, there is no distribution channel other than Flatpak, so if you are on a system where you cannot or will not install Flatpak, Workbench is not available to you. Second, the Flathub build is the only one that receives support, which means the package on Flathub is the artefact to look at when you are evaluating what you would actually run.

The application is published on Flathub with the identifier re.sonny.Workbench, and the project also has a presence on the GNOME applications site at apps.gnome.org/Workbench.

The second constraint has a subtler effect. Since the build is a Flatpak, the versions of the GNOME platform, of the language runtimes and of the toolchains available inside it are fixed by whoever built the package. A language runtime that has moved on in the host system may lag inside the sandbox, and that is a common source of confusion for people who expect a native install to behave like a sandboxed one, or the other way round.

## A per language formatter and linter pipeline

The package manifest in the repository root shows the JavaScript side of the development tooling, and the most interesting part is the lint-staged configuration.

```json
  "lint-staged": {
    "*.{json,md,yaml,yml}": "prettier --write",
    "*.{js,cjs,mjs}": "eslint --fix",
    "*.css": "./build-aux/fun workbench-cli format css",
    "*.py": "./build-aux/fun workbench-cli format python",
    "*.rs": "./build-aux/fun rustfmt --edition 2021",
    "*.blp": "./build-aux/fun workbench-cli format blueprint",
    "*.vala": "./build-aux/fun workbench-cli format vala"
  }
```

Each file type is routed to the right tool, and the CSS, Python, Blueprint and Vala cases all go through a workbench-cli format subcommand, which means the application ships the logic that formats those languages rather than delegating to an external binary. Rust goes to rustfmt with an explicit edition, and JavaScript goes to eslint with fix, matching the ESLint and Prettier configuration in the repository root.

This is also the answer to a question every user of the app eventually asks. The README's tips include how to disable code formatting, pointing at the Biome documentation for JavaScript and the Prettier documentation for CSS, so you can turn the automatic reformat off per language when it fights your style.

The same idea appears in the Makefile, where the lint target runs eslint for JavaScript, rustfmt for Rust, ruff check and ruff format for Python, and bluep for Blueprint, each inside the development environment rather than on the host.

## Building from source means flatpak, foundry and gjspack

The Makefile is the build entry point, and the setup target shows what a development environment needs.

```bash
setup:
	flatpak $(FLATPAK_ARGS) remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
	flatpak $(FLATPAK_ARGS) install --or-update --noninteractive flathub org.gnome.Sdk//51 org.flatpak.Builder org.freedesktop.Sdk.Extension.rust-stable//26.08 org.freedesktop.Sdk.Extension.vala//26.08 org.freedesktop.Sdk.Extension.llvm22//26.08 org.freedesktop.Sdk.Extension.node26//26.08 org.freedesktop.Sdk.Extension.typescript//26.08
	git submodule update --init
	npm install --no-fund
```

Read that list carefully, because it is the real dependency profile of the project. The GNOME SDK at version 51, the Flatpak Builder, and the freedesktop SDK extensions for Rust, Vala, LLVM, Node and TypeScript. Every language the workbench claims to support needs its runtime extension inside the sandbox, and the Node extension is what runs the JavaScript tooling.

The build itself uses foundry, with a stable target that builds build-aux/re.sonny.Workbench.json and a devel target for the development variant, and the default build target depends on devel. There is a separate cli target that packages the command line interface with gjspack from the troll directory, which is the same machinery the application itself uses to bundle its JavaScript.

The Makefile also lists unit, test, ci, sandbox and flatpak targets, and the repository carries a meson.build, a gi-types directory for the GObject introspection bindings, and a demos directory. The package.json declares the project as private, which fits an application rather than a library.

One constraint to keep in mind when you plan around this: the toolchain is pinned to specific SDK versions, so building Workbench for a different GNOME release is a matter of changing the SDK version, not just a rebuild.

## A 2023 release tag with commits landing in 2026

The project is GPLv3, with the licence in the COPYING file, and it is copyright 2022 Sonny Piers and contributors.

The version story needs the same care as the other facts here. The single listed release is v45.0 from 2023-09-22, and the last push to the repository was on 2026-09-28. So the code is being worked on, and the published tag is three years older than the newest commit.

For a Flatpak distributed application this is less alarming than it would be for a library, because what users install is the Flathub build rather than a version they pick from a tag. The number that matters to a user is the build on Flathub, not the tag on GitHub. For a contributor, the practical implication is that you work against the main branch and follow the release process rather than checking out a tag.

The credits section is worth reading for a different reason. It lists the components the application is assembled from, including Flatpak, GTK, GLib, GtkSourceView, libadwaita, VTE, GJS, Blueprint, Vala, the icon development kit, GTKCssLanguageServer, gtk-rs and PyGObject. That is an accurate picture of a GTK application assembled from a dozen upstream projects, and it explains why a change in any one of them can affect Workbench.

The project follows the GNOME Code of Conduct, and contributions go through the CONTRIBUTING.md file in the repository root, with the GNOME developer and contributor guidelines linked from the README.

## Conclusion

Workbench suits a developer learning GTK or libadwaita, or anyone who wants to mock up a GNOME interface in an afternoon rather than a sprint, since the live preview and the example library remove the slowest part of learning a declarative toolkit. It does not suit a team that needs a maintained release train, since the newest tag on record is v45.0 from 2023-09-22 even though the last push was on 2026-09-28, and it does not suit anyone who cannot install Flatpak, because the README states that only the Flathub build is supported. Before you plan a project around it, check the example count for the language you intend to use, since the README lists 103 JavaScript, 98 Python, 92 Vala and 52 Rust demos as of 2024-06-16, and treat the workbench output as a prototype, because the README itself points you to GNOME Builder templates to turn a prototype into a real application.

## FAQ

### What is Workbench used for?

Workbench lets you experiment with GNOME technologies and build and test a GTK user interface with a live GTK and CSS preview, supporting JavaScript, Rust, Python and Vala, with declarative user interface syntax through Blueprint.

### How do I install Workbench?

The README states that Workbench is made possible by Flatpak and that only the Flathub version is supported. The application is published on Flathub under the identifier re.sonny.Workbench.

### Which languages does Workbench have examples for?

The README table lists 103 library demos for JavaScript, 98 for Python, 92 for Vala and 52 for Rust, counted as of 2024-06-16. Blueprint and CSS have formatter support but no demo count.

### Can I use the Workbench examples in my own project?

Yes. The README states that everything under src/Library/demos is in the public domain under the terms of CC0 1.0, while the rest of the project is licensed GPLv3.

### How do I turn a Workbench prototype into a real application?

The README tips say to use GNOME Builder to start a new project from the appropriate GNOME Application template and copy the Workbench code across. The application itself is not a project generator.

## Sources

- [License: GPL-3.0](https://github.com/sonnyp/Workbench/blob/main/LICENSE)
- [Project website](https://apps.gnome.org/Workbench)
- [README](https://github.com/sonnyp/Workbench/blob/main/README.md)
- [Releases](https://github.com/sonnyp/Workbench/releases)
- [sonnyp/Workbench on GitHub](https://github.com/sonnyp/Workbench)

---

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