Category: GNOME

We are in the process of introducing a new decision-making process into the GNOME project. The specification of the RFC process is available as a merge request on GitLab. The discussion is happening on the respective Discourse thread. I am now announcing the start of the final comment period for the adoption of this RFC process. We are deviating from the proposal’s 14-day period for this occasion and instead will consider concerns raised up until October 4th at 23:59 UTC. All active GNOME Foundation members remain invited to contribute to the discussion.

The proposal of this RFC process is part of a broader initiative to improve the governance and coordination within the GNOME project. You can learn about other initiatives in Emmanuele Bassi’s latest Some more governance talk, and his older Governance in GNOME blog post.

July is Disability Pride Month. I want to use the occasion to speak about my perspective on accessibility in GNOME and what I think we should do.

For disabled people, computers are often even more important than for abled (non-disabled) people. Many areas of everyday life are currently only accessible via a computer for many disabled people. Still, accessibility is often an afterthought in software and hardware development.

GNOME is fortunate enough to have many disabled contributors in its community. We have contributors who are visually impaired, deaf, autistic, ADHD, or who live with migraines and other chronic conditions. While we have people that care about accessibility and work on improving it, the general state is far from ideal.

The reality of tech communities is that they are often ableist and elitist. Probably more so than the average population. If a user or contributor struggles with a tool, blame is shifted to a “skill issue,” if an interface is simplified to make it accessible to more people, it’s “dumbed down”. Assistive technologies are often developed by abled people, without involving and paying disabled people. This also leads to an attitude where contributors expect gratefulness from disabled people for providing them with the most basic needs. All these issues are also not absent from the GNOME community.

What We Already Do

The goal of this section isn’t to boast about GNOME’s accessibility efforts. I believe that accessibility is a fundamental right, and nothing any disabled person is obligated to praise contributors for. Instead, the goal is to capture where we stand, and give other projects ideas they can adopt. Equally, I would be very happy to learn how other FLOSS projects try to work towards better accessibility.

Our review criteria for Core and Circle apps require checking if keyboard navigation, screen reader support, large text, and high contrast mode work. We also require sufficient contrast in apps, which we usually use the Contrast app to check against the WCAG requirements. We have shown that we are able to enforce these requirements by delaying the inclusion or replacement of apps until accessibility issues were actually fixed. That’s also an improvement GNOME has seen over the last years, since originally, no quality criteria for apps existed.

Many of the accessibility aspects are automatically covered by using our toolkits GTK and libadwaita correctly. I witnessed that accessibility is often considered during initial design and implementation. However, we don’t have any guidelines or requirements in GNOME for the development of these libraries.

The GNOME Foundation funded work on screen reader support in GTK 4 in 2020 and 2021. In 2023 and 2024, accessibility was also one of the larger areas the GNOME STF project worked on. That means both the GNOME Foundation, and the STF organizers were willing to allocate money for accessibility, which is a good sign.

However, accessibility is so much more than screen reader support. I think that GNOME’s general design philosophy is very important to being more accessible to a broader audience. This includes the focus on simplicity with good defaults, trying to avoid the possibility of misconfiguring the system, and the attempt to distract less. Translations, while often overlooked as an accessibility aspect, are another huge factor that makes our software accessible to so many more people. This shows that accessibility is hardly a separate set of features. Instead, it has to be considered as part of every area in a project.

Among the more “traditional” accessibility tools within GNOME are the screen reader, high contrast, reduced motion, always show scrollbars, sound over-amplification, input adjustments, and magnification. But equally important are the “Dark Mode” and “Do Not Disturb” mode, which are not directly labeled as accessibility.

How We Can Improve

Disability Pride is about being proud of who you are. But, like Queer Pride, it is also about fundamentally changing the society in which we live. Hence, for this year’s Disability Pride, I am also thinking of what we can change within GNOME.

Create an Accessibility Team

Except for a dedicated accessibility chat room, there is currently very little coordination for accessibility within GNOME. My goal for this month is to establish a formal Accessibility Team. My initial ideas for the team are to prioritize voices of those with lived experience, instead of having others make decisions for us. Nothing about us without us. In more practical terms, the team should help to maintain and develop guidelines and review criteria that are especially relevant for accessibility. The team should also review larger changes in the GNOME project that affect accessibility. Ideally, we could provide and user testing on accessibility features directly from the people who rely on them.

In addition to guarding the accessibility aspects of the software we produce, the team should also advocate for accessibility in our events, workflows, and tooling.

If you are interested in contributing, please reach out via #a11y or in our issue #1. Let us know where and how you want to contribute.

Use This Month Yourself

If you are disabled, and you want to share your experience in FLOSS communities or have accessibility issues in GNOME or other FLOSS software, report the issues and/or post about them on social media under #AccessibilityInFreeSoftware.

If you are a contributor, see if you can tackle one of the roughly 450 open issues that are labeled with “Accessibility” this month. Try to broaden your horizons by reading articles from disabled people you know less about, or follow them on a social media platform. Embrace accessibility as a fundamental human right, not something disabled people have to show gratefulness for. Try to reflect on your language. Don’t use sanist language like “sane defaults,” using “good defaults” does the job. Ask yourself if you want to keep words like “idiot” in your vocabulary, knowing that “idiocy” was the first category the Nazis used to systematically kill people.

But also, don’t be scared of disabled people. We want to and deserve to be part of the community like everyone else.

Happy Disability Pride Month! Let’s build a desktop that is accessible to as many people as possible.

This blog post represents my personal opinions and not those of any organization I work for.

We want to share some updates and future plans from the GNOME Circle Committee with you. The Circle Committee is responsible for reviewing and accepting apps and other components into GNOME Circle as well as maintaining the review criteria.

The biggest issue for us, and for maintainers who submitted apps, has been the considerable backlog of unreviewed apps. There are cases where apps have been waiting for feedback for years. We are very sorry for those who have been affected by this. We are trying to finally address this issue now.

AI Policy

As a precaution, we have adopted the AI policy that already applies to GNOME Shell extensions. With the rise of low-quality machine-generated software, there is a risk that GNOME Circle could be overwhelmed by new submissions of this nature, further clogging the review queue.

This policy is a starting point, and for now, it will only be enforced on new submissions. We are open to receiving feedback on the AI policy from existing Circle maintainers. In a quick survey, 62% of Circle maintainers reported not using LLMs at all, 34% reported using them for small questions or snippets, and only 3% are taking larger parts of code from them. No maintainer selected the option for no longer writing code themselves.

Meanwhile, Flathub has also tightened their AI policy. Since GNOME Circle apps are usually expected to be published on Flathub, this policy indirectly applies as well.

Closing New Submissions

To make sure that we are focusing on submissions that haven’t been addressed for a long time, we will stop accepting new submissions for now. We will reopen submissions when we have made a considerable dent in our backlog.

New Handling of Issues

This is mostly a technical detail, but from now on, we will close issues that are awaiting feedback from the maintainer. When providing an answer, maintainers should just reopen the issue. This gives us a better overview of which issues are awaiting further processing by us.

Early Reminder About the Use of Outdated SDKs

Every GNOME release cycle, we spend a considerable amount of time on getting GNOME Circle apps to update their SDK on Flathub before the SDK becomes unmaintained. To avoid this in the future, we will try something new: We will remind maintainers much earlier that they are using an outdated SDK – months before it reaches EOL, rather than just a few weeks. This means apps using the GNOME 49 SDK will soon be part of an automatically generated reminder issue. To get the reminder, please make sure that you have provided a GNOME GitLab account in your project’s .doap file.

Growing Benefits

We are steadily growing the benefits for GNOME Circle apps and their maintainers. Among the benefits that were added are:

• Having a student work on your project for Google Summer of Code or Outreachy.
• Hosting your help pages on help.gnome.org.
• Getting a tag for your project on GNOME’s Discourse.

Of course, all contributors and maintainers of GNOME Circle projects are still eligible for GNOME Foundation membership. You can check our full list of benefits.

Call for Reviewers

We are in constant need of more reviewers in the Circle Committee. If you have already reached out to us, and we haven’t gotten back to you, please give it another shot. You can find us in #circle:gnome.org.

Yesterday, I wanted to debug a glycin (or Shell) issue on GNOME OS. Turns out, there is currently no documentation that works or includes all necessary steps.

Here is the simplest variant if you don’t develop on GNOME OS and have an internet connection that can download 16 GB in a reasonable amount of time.

First we get a toolbox image to build our code.

$ toolbox create gnomeos-nightly -i quay.io/gnome_infrastructure/gnome-build-meta:gnomeos-devel-nightly

After entering the toolbox with

$ toolbox enter gnomeos-nightly

we can clone and build our project with sysext-utils that are included in our image:

$ meson setup ./build --prefix /usr --libdir="lib/$(gcc -print-multiarch)"
$ sysext-build example ./build

This creates a example.sysext.raw file.

Now, we need a GNOME OS to test our build. We can download the image and install it in Boxes. After logging in, we can just drag and drop the example.sysext.raw into the VM.

Before we can install it, we need to get the development tools for our VM:

$ run0 updatectl enable devel --now

After that, we need to restart the VM.

Finally, we can test our build:

$ run0 sysext-add ~/Downloads/example.sysext.raw

Adding the --persistent flag to this command will make the changes stay active across reboots.

If the changes made it impossible to boot into the VM again, we can start the VM in “Safe mode” from the boot menu. After logging in, we can manually remove the extension:

$ run0 rm /var/lib/extensions/example.raw

Happy hacking!

Painkillers are essential. (There are indicators that Neanderthals already used them.) However, many people don’t know about aspects of them, that could be relevant for them in practice. Since I learned some new things recently, here a condensed info dump about painkillers.

Many aspects here are oversimplified in the hope to raise some initial awareness. Please consult your doctor or pharmacist about your personal situation, if that’s possible. I will not talk about opioids. Their addiction potential should never be underestimated.

Here is the short summary:

• Find out which substance and dose works for you.
• With most painkillers, check if you need to take Pantoprazole to protect your stomach.
• Never overdose paracetamol, never take it with alcohol.
• If possible, take pain medication early and directly in the dose you need.
• Don’t take pain medication for more than 15 days a month against headaches. Some mediaction even fewer days.
• If you have any preexisting conditions, health risks, or take additional medication, check very carefully if any of these things could interacts with your pain medication.

Not all substances will work for you

The likelihood of some substances not working for some sort of pain for you is pretty high. If something doesn’t seem to work for you, consider trying a different substance. I have seen many doctors being very confident that a substance must work. The statistics often contradict them.

Common over the counter options are:

• • Ibuprofen
  • Paracetamol
  • Naproxen
  • Acetylsalicylic Acid (ASS)
  • Diclofenac

All of them also reduce fever. All of them, except Paracetamol, are anti-inflammatory. The anti-inflammatory effect is highest in Diclofenac and Naproxen, still significant in Ibuprofen.

It might very well be that none of them work for you. In that case, there might still be other options to prevent or treat your pain.

Gastrointestinal (GI) side effects

All nonsteroidal anti-inflammatory drugs (NSAIDs), that is, Ibuprofen, Naproxen, ASS, and, Diclofenac can be hard on your stomach. This can be somewhat mitigated by taking them after a meal and with a lot of water.

Among the risk factors you should be aware of are Age above 60, history of GI issues, intake of an SSRI, SNRI, or Steroids, consumption of alcohol, or smoking. The risk is lower with Ibuprofen, but higher for ASS, Naproxen, and, especially, Diclofenac.

It is common to mitigate the GI risks by taking a Proton Pump Inhibitor (PPI) like Pantoprazole 20 mg. Usually, if any of the risk factors apply to you. You can limit the intake to the days where you use painkillers. You only need one dose per day, 30–60 minutes before a meal. Then you can take the first painkiller for the day after the meal. Taking Pantoprazole for a few days a month is usually fine. If you need to take it continuously or very often, you have to very carefully weigh all the side effects of PPIs.

Paracetamol doesn’t have the same GI risks. If it is effective for you, it can be an option to use it instead. It is also an option to take a lower dose NSAIDs and a lower dose of paracetamol to minimize the risks of both.

Metamizole is also a potential alternative. It might, however, not be available in your country, due to a rare severe side effect. If available, it is still a potential option in cases where other side effects can also become very dangerous. It is usually prescription-only.

For headaches, you might want to look into Triptans. They are also usually prescription-only.

Liver related side effects

Paracetamol can negatively affect the liver. It is therefore very important to honor its maximum dosage of 4000 mg per day, or lower for people with risk factors. Taking paracetamol more than 10 days per month can be a risk for the liver. Monitoring liver values can help, but conclusive changes in your blood work might be delayed until initial damage has happened.

A risk factor is alcohol consumption. It increases if the intake overlaps. To be safe, avoid taking paracetamol for 24 hours after alcohol consumption.

NSAIDs have a much lower risk of affecting the liver negatively.

Cardiovascular risks

ASS is also prescribed as a blood thinner. All NSAIDs have this effect to some extent. However, for ASS, the blood thinning effect extends to more than a week after it has been discontinued. Surgeries should be avoided until that effect has subsided. It also increases the risk for hemorrhagic stroke. If you have migraine with aura, you might want to avoid ASS and Diclofenac.

NSAIDs also have the risk to increase thrombosis. If you are in as risk group for that, you should consider avoiding Diclofenac.

Paracetamol increases blood pressure which can be relevant if there are preexisting risks like already increased blood pressure.

If you take ASS as a blood thinner. Take Aspirin at least 60 minutes before Metamizole. Otherwise, the blood thinning effect of the ASS might be suppressed.

Effective application

NSAIDs have a therapeutic ceiling for pain relief. You might not see an increased benefit beyond a dose of 200 mg or 400 mg for Ibuprofen. However, this ceiling does not apply for their anti-inflammatory effect, which might increase until 600 mg or 800 mg. Also, a higher dose than 400 mg can often be more effective to treat period pain. Higher doses can reduce the non-pain symptoms of migraine. Diclofenac is commonly used beyond its pain relief ceiling for rheumatoid arthritis.

Take pain medication early and in a high enough dose. Several mechanisms can increase the benefit of pain medication. Knowing your effective dose and the early signs to take it is important. If you have early signs of a migraine attack, or you know that you are getting your period, it often makes sense to start the medication before the pain onset. Pain can have cascading effects in the body, and often there is a minimum amount of medication that you need to get a good effect, while a lower dose is almost ineffective.

As mentioned before, you can combine an NSAIDs and Paracetamol. The effects of NSAIDs and Paracetamol can enhance each other, potentially reducing your required dose. In an emergency, it can be safe to combine both of their maximum dosage for a short time. With Ibuprofen and Paracetamol, you can alternate between them every three hours to soften the respective lows in the 6-hour cycle of each of them.

Caffeine can support the pain relief. A cup of coffee or a double-espresso might be enough.

Medication overuse headache

Don’t use pain medication against headaches for more than 15 days a month. If you are using pain medication too often for headaches, you might develop a medication overuse headache (German: Medikamentenübergebrauchskopfschmerz). They can be reversed by taking a break from any pain medication. If you are using triptans (not further discussed here), the limit is 10 days instead of 15 days.

While less likely, a medication overuse headache can also appear when treating a different pain than headaches.

If you have more headache days than your painkillers allow treating, there are a lot of medications for migraine prophylaxis. Some, like Amitriptyline, can also be effective for a variety of other kinds headaches.

As some of you know, I like aggregating data. So here are some random numbers about GNOME in 2025. This post is not about making any point with the numbers I’m sharing. It’s just for fun.

So, what is GNOME? In total, 6 692 516 lines of code. Of that, 1 611 526 are from apps. The remaining 5 080 990 are in libraries and other components, like the GNOME Shell. These numbers cover “the GNOME ecosystem,” that is, the combination of all Core, Development Tools, and Circle projects. This currently includes exactly 100 apps. We summarize everything that’s not an app under the name “components.”

GNOME 48 was at least 90 % translated for 33 languages. In GNOME 49 this increased to 36 languages. That’s a record in the data that I have, going back to GNOME 3.36 in 2020. The languages besides American English are: Basque, Brazilian Portuguese, British English, Bulgarian, Catalan, Chinese (China), Czech, Danish, Dutch, Esperanto, French, Galician, Georgian, German, Greek, Hebrew, Hindi, Hungarian, Indonesian, Italian, Lithuanian, Persian, Polish, Portuguese, Romanian, Russian, Serbian, Serbian (Latin), Slovak, Slovenian, Spanish, Swedish, Turkish, Uighur, and Ukrainian. There are 19 additional languages that are translated 50 % or more. So maybe you can help with translating GNOME to Belarusian, Catalan (Valencian), Chinese (Taiwan), Croatian, Finnish, Friulian, Icelandic, Japanese, Kazakh, Korean, Latvian, Malay, Nepali, Norwegian Bokmål, Occitan, Punjabi, Thai, Uzbek (Latin), or Vietnamese in 2026?

Talking about languages. What programming languages are used in GNOME? Let’s look at GNOME Core apps first. Almost half of all apps are written in C. Note that for these data, we are counting TypeScript under JavaScript.

The language distribution for GNOME Circle apps looks quite different with Rust (41.7 %), and Python (29.2 %) being the most popular languages.

Overall, we can see that with C, JavaScript/TypeScript, Python, Rust, and Vala, there are five programming languages that are commonly used for app development within the GNOME ecosystem.

But what about components within GNOME? The default language for libraries is still C. More than three-quarters of the lines of code for components are written in it. The components with the largest codebase are GTK (820 000), GLib (560 000), and Mutter (390 000).

But what about the remaining quarter? Line of code are of course a questionable metric. For Rust, close to 400 000 lines of code are actually bindings for libraries. The majority of this code is automatically generated. Similarly, 100 000 lines of Vala code are in the Vala repository itself. But there are important components within GNOME that are not written in C: Orca, our screen reader, boasts 110 000 lines of Python code. Half of GNOME Shell is written in JavaScript, adding 65 000 lines of JavaScript code. Librsvg and glycin are libraries written in Rust, that also provide bindings to other languages.

We are slowly approaching the end of the show. Let’s take a look at the GNOME Circle apps most popular on Flathub. I don’t trust the installation statistics on Flathub, since I have seen indications that for some apps, the number of installations is surprisingly high and cyclic. My guess is that some Linux distribution is installing these apps regularly as part of their test pipeline. Therefore, we instead check how many people have installed the latest update for the app. Not a perfect number either, but something that looks much more reliable. The top five apps are: Blanket, Eyedropper, Newsflash, Fragments, and Shortwave. Sometimes, it needs less than 2 000 lines of code to create popular software.

And there are 862 people supporting the GNOME Foundation with a recurring donation. Will you join them for 2026 on donate.gnome.org?