neighbourhoodie-nnh-logo

NH:STA S02E1 GNOME posted Wednesday, July 22, 2026 by The Neighbourhoodie Team AnnouncementNewsInterviewSovereign Tech AgencyFOSS

This post is part of our looking back on our work for the STA, formerly the Sovereign Tech Fund. Our introduction post explains why and how we contributed to various Open Source projects. Read on to discover what we did for GNOME and how we can help you with your open source goals.

Introducing GNOME

If you’ve recently considered ditching your proprietary operating system in favour of something free and open source, you’re not alone. There’s been a marked uptick in people trying out or moving entirely to Linux, particularly over the last year. One of the projects making the transition to Unix-based environments familiar and user friendly is the GNOME project, which coordinates and releases the GNOME operating system.

Like with any operating system, GNOME offers a wealth of familiar applications awaiting your notes, calendar entries, reminders, music playlists, contacts, and more — everything you need to boot up so you can be productive. Except in a GNOME environment, you get to skip ads and bloatware, and remain in control of which versions and updates you choose to work with. Because it’s open source, you can also fork and make local changes to the apps you’re using so they better suit your needs. You can also make contributions for other users.

This flexibility and independence has been at the core of the GNOME mission since it was founded in 1997, and was a motivating factor behind founding the GNOME Foundation in 2001. Millions of users rely on GNOME’s desktop apps and development tools, so it’s no surprise the Sovereign Tech Agency considers their project a cornerstone of the FOSS ecosystem and has awarded two funding rounds to reflect that.

What We Worked On

While end-users will benefit from the impact of our work, many contributors to the project will interact with it directly, which is incredibly exciting.

At the time of writing, GNOME’s graphical interfaces use the widget-based GTK toolkit written in C. This allows for functions within a tool to run separately, which allows greater degrees of functional complexity; it’s the toolkit of choice for popular apps like Inkscape, Libre Office and Mozilla Firefox. To make the creation of UIs with GTK4 easier — and to help reduce the amount of C coding that needs to go into them — you can use a GTK builder which parses descriptions of the UI, for example written in XML, and builds them at runtime. Basically, instead of needing to code any changes to your UI and their interactions, you can update the XML description of the UI and let the GTK toolkit take care of the rest.

GNOME currently maintains two parallel systems to generate GTK4 user interfaces: the legacy XML syntax and the newer, more modern Blueprint. While it’s more user friendly and has fewer limitations than XML, it’s still experimental and undergoing development.

One of the goals for Blueprint’s development is to develop a linter to aid developers as they work. Linters are style-focused analysis tools that check your code against a set of coding standards defined by the project behind the build infrastructure they’re implemented within. It’s completely up to project members to decide what rules they want their linter to enforce, and they consistently evolve. Generally, they help with code quality, consistency and performance by looking out for stuff like:

  • Logical flaws
  • Redundancies
  • Syntax errors or preferred alternatives
  • Design errors
  • Accessibility issues
  • Compatibility, version or licensing issues
  • Spelling mistakes

They also play a wider role in a project’s health:

  • Linters lower the bar to entry for newcomers by providing feedback early, so it’s a bit easier to get accustomed to a project.
  • Thanks to consistent standard enforcement, linters enhance code readability for everyone.
  • By making it easier to check code quality from the outset, PR reviewers have fewer things to look out for and can focus on big picture functionality.

The GNOME project asked us for help with the creation of the Blueprint linter, starting with working out which rules it should enforce.

Creating a Linter Rule Report

Luckily, we didn’t have to start defining linter rules from scratch. Project members had already been discussing what would be useful before we came along, so we could understand what the new linter would need to prioritise.

We could also take a look at relevant legacy system linters and determine what would be helpful in the Blueprint system. For example, gla11y is an accessibility-focused linter from GNOME’s legacy build infrastructure that you might recognise if you’re a LibreOffice contributor. We could both grab from this what is still relevant, but also take note of improvements folks had already suggested.

When we were ready, we shared our report with the project to get feedback.

Developing the Blueprint Linter

Next came the exciting part: building the linter.

We focused on implementing highest-impact rules first — common errors and pitfalls developers are likely to run into. As we went, we created some light documentation on using the linter that helps new users understand what the linter looks out for.

Now that’s available, you can set it up and welcome its helpful hints from your code editor. Next we hear from Ninette Adhikari, Julia Krüger and James Coglan about their experience working on the project.

Reflections from the Team

What was Especially Challenging about Working on the Gnome Project?

Ninette: Setting up a virtual machine to run the tests was tricky. But it would have taken us so much longer without doing that.

Julia: Yes exactly. To run the blueprint-compiler we had to set up a virtual environment with Fedora on our MacBooks since it does not run on MacOS. We worked out a workflow so we could edit the code and use git in our usual MacOS environment, but run the code to test it in Fedora quickly. This was a bit cumbersome but worked out fine in the end.

James: There’s always a learning curve when writing language tooling as you get familiar with how the language works and how it can be processed and manipulated. Fortunately the Blueprint project is organised in a way that makes it easy to reuse the parsing tools, so after a bit of time establishing some common patterns we were able to add new linting rules quite quickly.

Conclusion

We hope our linter contributions have made coding your GNOME apps a little easier and more delightful. We got to flex our Python skills for this one, and get a bit more practised at setting up VMs — something that will certainly come in handy in the future. As always, we’re very grateful to the project for inviting us to help out.

You can read more about the work we’ve done on different FOSS projects with the support of the Sovereign Tech Agency:

And you can get a peek at the projects we haven’t yet written about in our series finale.

We Can also Help You Directly

Many companies and products have crucial dependencies on small and potentially understaffed and underfunded FOSS projects. We can help identify and improve the ones that are important to your business. Our friendly sales team is happy to help. Book a call with us today!

« Back to the blog post overview
og-image-preview