International ME/CFS Awareness Day

May 12 is the International ME/CFS Awareness Day. Since I have been living with ME/CFS for some time, I want to use this day as an opportunity to talk a bit about this topic.

The Illness

The main symptom of ME/CFS is an intolerance against physical, cognitive, and emotional exertion. For me, that means that activities like preparing dinner or cleaning my room can overload my body. Usually, the full consequences of this only become visible after roughly 24 hours. The state after such an overload is also called a crash. The resulting symptoms for me include exhausted muscles, feeling like I got the flue, pain in joints and muscles, disrupted sleep, brain fog, headaches, and more. Depending on the severity, these symptoms will disappear again after a day or a week of rest. Not resting during a crash, is an easy way to prolong the symptoms and just feeling incredibly miserable. Following these limitations is a bit challenging at times. Therefore, some of these symptoms are quite a frequent issue for me.

In contrast to severe cases of ME/CFS, I’m usually still having a considerable amount of energy available, with a score of 30 on the CFIDS Disability Scale. Cases with a score 0, which implies being constantly bedridden and unable to care for oneself, do exist. One of the recent more prominent cases has been the one of Diana (Physics Girl).

While I am able to manage my every day life, having to manage my resource that much, and planning ahead for basic tasks like my weekly hair wash is quite exhausting. Not having extra resources available for unexpected events in life is honestly also pretty frightening at times. Due to ME/CFS and other disabilities like Autism, I have been at “full reduced earning capacity” for more than 10 years now. That’s the formal term in Germany for people that can’t work at least 3 hours per day.

Perspectives for Treatment

ME/CFS is a syndrome, a label for a collection of symptoms that have been observed in many patients. Nobody knows what’s the cause, how it works, or even if it’s one illness or a bunch of illnesses that all manifest similarly. Equally, there is no direct treatment. There are some treatments that can be tried to manage some of the symptoms, but usually, it needs some luck to find anything that has any positive effect. Generally, ME/CFS can get better on its own. But, like everything with ME/CFS, the likeliness of this happening is unknown.

The key in managing ME/CFS is pacing. That means knowing one’s body’s limits and trying to not exceed them. This is especially important since, as described before, the main symptoms have a very delayed onset, making it impossible to just rely on the direct feedback of one’s body. If the body is clearly reacting, I am already deep in crash territory. For me, that especially means to limit physical activities like vacuuming to not more than 30 minutes and to lie down afterward. Walking is currently possible up to about 1 km on good days. But I am still struggling to follow what I know is good for me. But I am improving.

ME/CFS can be caused by infections like influenza or COVID. While COVID can cause a lot of different health issues, often lumped together under the vague term ‘long COVID’, ME/CFS is one of these potential long term effects. ME/CFS has long been mostly ignored by medical research, or worse, been labeled as a psychological problem that can be fixed by “just going out more” – which of course just worsens the symptoms. Even still, large studies are published that try to support these theories. While these studies are of laughable quality (German), they managed to hinder proper research and treatment for ME/CFS for far too long. What’s even more infuriating is that some of these studies seems to be influenced by insurances that want to avoid claims by ME/CFS patients. But COVID brought ME/CFS enough attention that things are slowly changing. A lot of trials for vastly different medications are ongoing. ME/CFS has also reached such an importance that treatment and research for it is explicitly mentioned twice in the coalition agreement of Germany’s new government. Research is slowly getting an idea of what is happening in the body of ME/CFS patients. Damaged Mitochondria, immune system reactions, changes in blood cells, involvement of the nervous system, abnormalities in brain MRI’s, and many more. However, it is still very much unclear which of these things are cause and which are effect.

Working on GNOME

I am very happy that I have the capacities to contribute to GNOME. Programming has been calming and fulfilling for me for a very long. I wish I could contribute more, but slowly chipping away on my projects is also fine :) Since last year, I have also started to accept donations and do a bit of contract work like for GNOME STF. This extra money, on top of my social benefits, helps me to buy some nice woodworking tools (I rarely have energy to use, oh no) or give me the luxury of not having to contemplate if I can afford to take a taxi to a doctor’s appointment. I am very grateful for that!

This was 2024

In non-chronological order

- Earned money for the first time within many many years.
- Wrote C bindings and GObject introspection annotations for a Rust library for the first time.
- Wrote 40 weekly updates on Patreon/Ko-Fi.
- Got formally diagnosed with Autism.
- Implemented some basic image editing in Loupe.
- Bought new woodworking tools.
- Got bold and worked on a few lines of security critical C-code.
- Confirmed with my doctors that the suspected diagnosis changed from fibromyalgia to ME/CFS.
- Dove into BuildStream to add for more complete Rust support.
- Released a collection of Rust crates that allow extraction, recomposition, and editing of image data including Exif or XMP for several image formats.
- Created a website that lists all GNOME components like libraries that are not apps.
- Called a Taxi for the first time in my life.
- Wrote Rust bindings for the C bindings of a Rust crate.
- Stopped occupational therapy and started another psychotherapy.
- Got interviewed by c’t Open Source Spotlight (German).
- Started ordering groceries online to have more energy for other things.
- Was proud (and still am) to be part of a community with such a strong pride month statement.
- Did a bunch of reviews for potential new GNOME Core apps.
- Expanded the crowdfunding of my work to Patreon, Ko-Fi, GitHub, and PayPal.
- Built a coat rack.

A huge thanks to everyone who supported my work!

Image Viewing and Editing in GNOME 47 and Beyond

Loupe is GNOME’s default image viewer since GNOME 45. It is powered by the newly written safe image loading and editing library glycin.

What’s new in 47

With GNOME 47, Loupe version 47 is available as well. This release mostly consists of a lot of subtle changes. For JPEGs, the image rotation feature now writes the new orientation to the image file. While Loupe 46 was still defaulting to an older GTK renderer, the new version is using the same defaults as all other apps. Thanks to work by Benjamin Otte in GTK, Loupe now also handles very large images (larger than 256 megapixels) reliably on systems with limited VRAM while also increasing the loading speed.

Loupe and the underlying image loading and editing library glycin now support much better error reporting if it is not possible to load an image. The new glycin version uses a different decoder for JPEG images, improving loading speed and fixing all known compatibility issues. As part of my work on the GNOME STF grant, glycin now also provides bindings for other programming languages than Rust including C, GJS, Python, and Vala. If necessary, glycin now automatically disables its sandbox features in Flatpak development environments, simplifying development.

What we are working on

But there is more! We have already merged the first GNOME 48 features, which will be released in March 2025. Allan Day worked on a new design for overlay controls, especially zoom. This is already implemented and merged. It allows the selection of zoom levels like 100% without using keyboard shortcuts like Ctrl+1 and additionally gives the option to select arbitrary zoom levels. There is also a new experimental design for dragging images into the Loupe window.

On the more technical side, Hubert Figuière has written an initial loader implementation for raw image formats which is now merged into glycin. Last but not least, I’m planning to finally have some initial image editing features beyond image rotation in Loupe 48. I’m currently working on all the basics and an image cropping feature.

A huge thanks goes out to everyone who contributed to this work including all the people that are kind enough to support my work financially! If you want to get weekly behind-the-scenes development updates or just support my work financially, you can do so via Patreon, Ko-Fi, GitHub, or OpenCollective.

Header Image © Friedrich Haag / Wikimedia Commons / CC BY-SA 4.0

Pika Backup Hopping Through Milestones

Pika Backup is an app focused on backups of personal data. It’s internally based on BorgBackup and provides fast incremental backups.

Last year, Pika Backup crossed the mark of 100,000 downloads on Flatub. These are numbers I couldn’t have imagined when submitting Pika Backup to Flathub only about three years ago. Thanks to everyone who has supported the project along the way. Be it with incredibly kind feedback, helpful issue reports, or financial contributions on Open Collective. It has been a blast so far. A special thanks goes to BorgBase who generously has been giving financial support to the project development for over a year now.

While we still have a bunch of features planned for Pika Backup, our focus remains stability and keeping the codebase maintainable. The project was started over five years ago. Since these were still the early ages of Rust as a programming language within GNOME, a lot has changed in the way app code is commonly structured. This means that we are also planning some refactoring work to help with the maintainability and readability of the code for future contributors.

After being blocked by a nasty bug for a while, we are finally releasing Pika Backup 0.7 today. Like the previous release, the new release has substantially been driven by Fina since I have been busy with other projects including moving flats. I’m thrilled that the project has two maintainers who are familiar with the codebase. The new release contains over 20 significant changes and fixes. The most noticeable new features are:

- A new preferences window to rename backup configurations and allow scheduled backups with the system running on battery.
- The ability to automatically run scripts before and after creating a backup.
- A new feature to check the backup repositories’ integrity.

You can financially support development on Open Collective or GitHub. If you want to support my general GNOME endeavors and get some behind-the-scenes updates, you can support me on my new Patreon.

If you want to try out BorgBase for hosting your backup you can get 10 GB storage for free on borgbase.com. A guide for setting up Pika Backup with BorgBase is available as well.

This was 2023

In non-chronological order

- Created a new library, called glycin, for image loading
- Spent a lot of time diamond painting
- Fixed a bunch of image decoding issues
- Had a lot of bureaucracy fun
- Dived much deeper than before into GTK code
- Moved flat after 14 years at the same place
- Chased a bunch of 32-bit issues with increasing obscurity
- Finished and published the Welcome To GNOME website
- Managed another mental health crisis
- Surprisingly didn’t get the rona this year
- Installed all skirting boards but one in my new room
- Wrote a small tool to track rust crate usage within GNOME
- Got gifted a wonderful try-square
- Learned that there are also psychotropics that noticeably help
- Helped to get our new Image Viewer codenamed Loupe into Core
- Noticed that energy is still quite limited and that it might be fibromyalgia
- Watched the queer conspiracy intensify
- Started writing libraries for Exif and XMP reading and editing
- Somehow ended up in the GNOME Release Team
- Started tiling things outside of image rendering
- Regained some body strength
- Setup a page on open collective for Pika Backup
- Launched a Websites Team for GNOME

Welcome to GNOME: A site to get started

Welcome to GNOME is a new site that allows you to explore how to get involved within GNOME. The pages are translated into different languages and provide customized instructions for more than 90 apps.

It’s the holiday season in many parts of the world. What better time to try out something new! On welcome.gnome.org you can now learn about the many ways to contribute within the GNOME ecosystem. The pages are currently completely available in Brazilian Portuguese, English, Indonesian, Russian, Swedish, and Ukrainian.

Motivation

Some of our resources for new contributors within GNOME have been outdated for a while. Like with apps.gnome.org, I noticed that creating a contributing page for an app is usually quite repetitive work and the instructions tend to get outdated quickly. Therefore I wanted to automate the process. Another chance that these new pages give us is to translate the content. I think this can be especially helpful for new contributors to get started.

What we have now

The contribution instructions for every app on the new pages are automatically generated from data that is already collected by apps.gnome.org’s software. The auto-generated information covers translation, Flatpak installation, nightly version, issue tracker, and links to the relevant documentation for the used programming language. The instructions on cloning and building the app and submitting changes afterward are also adjusted to the app and the used git forge. This should usually provide all the information to get started with contributing to an app.

“Welcome to GNOME” start page in Ukrainian

There are also pages for the Design and the Websites team available. A page about programming has general information on how to get started with coding. The Translation and Documentation teams decided to not provide pages on the new website.

Things that I would like to cover in the future are libraries and everything else that’s not apps but part of GNOME. However, I don’t have any concrete plans for this yet.

Thanks

Thanks to all the people who helped with proofreading the content and for the valuable feedback. Thanks also to the designers who helped with further tweaking the pages and to the translators for their work.

Resources

Viewing Images in GNOME: Loupe and Glycin

Loupe is GNOME’s new Core app for viewing images. Starting with the GNOME 45 release, you might find it as Image Viewer on your system. It replaces the previous image-viewing app Eye of GNOME. In honor of this historic occasion, I wanted to give a bit of insight into the making and technology of Loupe.

Why Start from Scratch

The first documented commits to Eye of GNOME (EOG) are from September 1999 by Federico. Some of this code from back then withstands the test of time until today. Likewise, the image loading was already powered by GdkPixbuf, which is still GNOME’s image loading library today. So why start replacing such a well-tried set of software now?

App window with a minimalist headerbar on top and an image of the Carina nebula below. — Loupe provides more than just a refreshed user interface.

Original experiments for writing a new image viewer go back to 2020. There wasn’t a complete technical plan for Loupe, but rather a gut instinct with everyone involved that for the goals of Loupe, a rewrite would be the better solution. In retrospect, this was the right decision. With the port to GTK 4, a new interface design, gestures and animations, sandboxed image loading, and using more upstream projects for decoding tasks, the code overlap wouldn’t have been too large to begin with. On top, the Rust language is a good fit for handling media data since it provides memory safety and performance at the same time.

Hidden Features

On the surface, Loupe looks simple. And that’s what we want it to feel like. Behind this, however, are a lot of features that make this possible. Here are a few examples that highlight the differences to EOG. The image rendering is now happening on the graphics card. That allows viewing quite large images while retaining a responsive interface, including animations and direct visual feedback for touchpad and touchscreen gestures. It also makes Loupe much more snappy on high-resolution screens, especially noticeable with higher refresh rates. To keep image navigation for SVGs smooth as well, Loupe uses “tiled rendering,” only rendering relevant parts of the SVG and providing those tiles to the graphics card for combining them. This allows Loupe to render large SVGs while keeping the interface responsive. Loupe also supports High DPI screens better in the way that a 100 % image size is oriented on the physical amount of pixels. For transparent images, Loupe analyzes the image’s content and chooses a different background color to not end up drawing black content on a black background and alike.

Dialog with layout options to the left an a print preview to the right showing a Pika. — Not all features new to Loupe are as apparent as the print layout dialog.

Last but not least, I wrote a new wrapper around the image decoding process. The project is named Glycin after a photographic developing agent. Glycin sandboxes the image loading, which potentially¹ adds security and allows a flawed image loader to crash without pulling Loupe down with it.² Additionally, most decoders Glycin uses are written in Rust, adding an additional line of defense via memory safety.

Rust Doesn’t Solve Everything

Duh! I know. But sometimes I feel like there is a tendency that one might forget that besides all the struggle with programming languages and build systems, programming in itself also remains hard. No matter the tools one uses. While the codebase at hand is still relatively small – about 8000 lines of Rust code – there were a bunch of logic and design challenges that required a day without brain fog³. One example is the combination of many input methods and animations and their potential interactions and always getting them represented correctly on the screen.

Another big part of this project was, as so often, working with upstream projects that make all the magic possible in the first place. The GTK maintainers took on the battle with OpenGL to add mipmapping support for better texture rendering. I even dipped my toes into GTK’s texture code myself to add support for gray-scale textures, apart from some smaller additions. We also discussed future GTK APIs for HDR images and ICC profiles in a call. Libadwaita also got some features needed for Loupe. The image decoding crates got a bunch of commits to add support for ICC color management profiles. For the libheif bindings, the maintainer took care of most of the needed changes.

I learned a bunch of new things during the development. About GTK internals, custom widgets, the dreaded OpenGL, image formats, color spaces, memfd, and more.

What will Break

Now, with replacing and changing so many bits an pieces, what will break? First of all, there are some limitations when using Loupe via Flatpak. This, however, was already the case with EOG. Using hardware acceleration also means that your graphics drivers have to work. In some rare occasions, like with the PinePhone (non-pro), this seems to be an issue. Switching to software rendering in those cases is possible, however. The tiled rendering code is not working as well as I would like it to. This can, for example, result in SVGs being rendered slightly blurry while using a pinch gesture to zoom. There can also be a short delay in animations for very large images or on older hardware. I did not have the time to properly address the issue for this release.

We are also replacing many of the image decoders with new ones. There are cases where the new image loading has better support for formats, and there are images that can’t be opened at all but work in EOG. The reason is mostly that many image standards have parts that have rarely been used in practice, and therefore, almost no image decoder implementation is 100 % complete. I’m sure that we will find some formats that are used in practice, and support has to be added in future versions. Maybe the fax encoding standards for TIFF?

We are shipping Loupe in its current state as a Core component since we are convinced that the benefits will outweigh the minor regressions we might hit. We also had the chance to confirm this through the feedback we got over the complete development and incubation period.

Closing Thoughts

Most of Loupe has been written over a timespan of nine months, with me also having to move flats during this time. None of the people who directly contributed to Loupe were paid for their work. On one hand, it is promising that we can pull such a project off as a community effort. On the other hand, considering how many companies will rely on such GNOME Core components, the balance does look off to me.

Big thanks go out to everyone who helped make this project happen: Chris, who started the whole project. Allan, for all the design work. Alice, Ivan, Zander, for a huge amount of help in all areas, especially touch gestures, and lower-level plumbing, and … even more gestures! The contributors to all the countless projects Loupe depends on. And everyone who helps with testing and is reporting issues.

The development of Loupe hasn’t been without friction. With the release of GNOME 45, I will be stepping down from maintaining Loupe to not stand in the way of the original ideas of how to run this project.

¹ While decoder processes don’t have write access to files and no network connection, I still consider the hardening of the sandbox in its infancy.

² For those who are interested in the technical details: Glycin spawns one sandboxed process per image file via bwrap or flatpak-spawn. The communication happens via peer-to-peer D-Bus over UNIX socket. The file data is read from a GFile and sent to the sandbox via a separate UNIX socket. The texture data is provided from the sandbox via a memfd that is sealed afterward and given as an mmap to GTK. For animations and SVGs the sandboxed process is kept alive for new frames or tiles as long as needed. For an introduction to this structure, see Christian Hergert, “Designing Multi-Process Application Security,” GUADEC 2019.

³ Developing software with chronic illness and disability would probably be worth a blog post on its own.

That was 2022

In non-chronological order

Released Pika Backup 0.4 with scheduled backups and GTK 4 & libadwaita
Started working on a “Welcome To GNOME” website
Refactored apps.gnome.org to share a lot of code with “Welcome to GNOME”
Reviewed some apps for GNOME Circle and made announcements for new apps that joined
Upped my espresso game to an entirely new level
Removed 2600 obsolete lines of code from GTK because YOLO
First time without therapy after seven years … kind of
Got the rona from who knows where
Contributed support for the keyring format to oo7
Got a bunch of new chisels for woodworking and linoleum print
Contributed to screenshot guidelines and landed new screenshots for half of the Core apps
Got awarded the GNOME community appreciation award
Met a bunch of new faces at Berlin mini GUADEC
Hosted a BoF about app organization
Brought app organization and the new incubation process to life
Dared to touch the Flatpak background portal to make autostarting apps work again
Made some minimal contributions to libadwaita for the looks
My money don’t jiggle jiggle
Managed to fix a nasty bug with notifications disappearing for Clock alarms that had been bugging me a lot
Finally glazed my first vase
Launched app.drey as a publicly available app id prefix
Continued the queer conspiracy
Dropped the overly specific Key Rack app on an unexpecting world
Started building a model windmill on a far too small scale
Started an initiative to fade out legacy app branding that had limited practical impact so far
Deleted all my twitter accounts
Been part of a successful initiative to remove gendered terms and price differences between fits from the GNOME shop
Tried to convince people that we want to pre-select the location shown in the file chooser with little success for the relevant people
Landed some features for Loupe, like rotation, zoom, scrolling, Exif metadata, and a bunch of bug fixes
Noticed that displaying images on computers is fundamentally impossible and flawed
Added support for sending links for specific views on app overview and made many new fields available
Finally ordered the cat ears.

Petrol espresso cup with espresso on wooden board

GUADEC and App Organization BoF

TL;DR: I attended my second GUADEC, got awarded the Community Appreciation Award, and still have questions about the future of conferences. Also, there is a ton of stuff coming up for the organization of apps within GNOME!

Berlin Mini GUADEC

Before GUADEC there was an astonishing Covid wave in Germany, so I finally somehow caught it despite not even really leaving my flat around this time. I was still feeling quite weak around GUADEC and also had to catch up with my preparation for the BoF I was hosting. More about the BoF below. I still managed to drop by for one evening, seeing some new faces and attending Tobias’ talk in person.

Despite still being pretty much a greenhorn within the GNOME community I was awarded this year’s Community Appreciation Award (aka “Pants of Thanks”.) I was very thankful that this year’s general assembly included a huge block of attributions to a lot of initiatives and contributions within the GNOME project. We have so many wonderful projects and contributors within the project that a single award is not nearly enough to cover everything that’s going on. I can’t deny that though felt flattered to receive an award for my work😊 I also had a pretty huge smile on my face when reading the hints as to who will be getting this year’s award.

comfortable with sharp tools to do woodworking

deeply cares about the public face of GNOME

fights for the rehabilitation of a small mammal, against one of the most icon Pokemon

The Future of Conferences

“Conferences are broken” is not really a hot take anymore and with what we know today about how different people learn and socialize it’s not really a surprise that there is not one format that fits everyone. Apart from the question about the usefulness of conferences in the current format, I wanted to boost awareness of some aspects of why in-person-only conferences can be exclusionary:

- For minoritized community members, it is more likely that the conference environment is unsafe, despite the event having a code of conduct.
- For some minoritized community members, travel is either not possible or much more challenging than for others.
- Some community members don’t find it environmentally responsible to travel long distances for such an event.
- For some disabled or neurodivergent community members, a traditional conference setting might not be feasible or very exhausting.
- For some community members, taking the time off might not be financially viable or they are bound to a location because of care work commitments.

There are probably more that I forgot or don’t know of.

So I hope that GUADEC will at least continue to enable remote participation. And maybe, one day, someone will find the time to ask the question of what the target audience of GUADEC is, what the conference should provide, and what the best formats for the audience are to achieve this.

App Criteria and Organization BoF¹

There has been ongoing work around organization, branding, review, and many more around apps. For an attempted overview, you can check my previous blog post. With this BoF we have found a consensus on how to go forward with many things around apps within GNOME!

- Going forward we will try to share a lot of criteria that we apply to apps when reviewing them for GNOME Core or GNOME Circle.
- We are planning to have a new Incubation Process for GNOME Core apps. This will allow for a more transparent way of creating new apps for GNOME Core and is also intended to get more feedback from the wider community as well as from other stakeholders like distributions during the app development.
- There will also be a clearer path on how and when apps can be removed from GNOME Core or GNOME Circle. Hopefully, this will make the process more transparent.
- We are also planning to have regular (every two years for now) reviews of GNOME Core and GNOME Circle apps to help maintainers with quality control and to potentially find ways to help with existing problems within the projects.
- We will finally have some more concrete and conceptual definitions of what GNOME Core Apps and GNOME Development Tools are. Those two groups will form the apps part of official GNOME software. We are also trying to define the role of GNOME Core App maintainers and the project ownership more clearly.

Most of those things are now documented in a central App Organization repository. The GNOME Circle Committee recently started relying on those new criteria. Hopefully, the Release Team can start introducing the new mechanisms to Core apps as well, soon. Of course, we will have to somewhat experiment with all of those new things as we go and might have to adjust them while we are gaining experience.

Huge thanks to everyone who has contributed to this effort so far! Recently especially Chris Davis who designed the incubation process and Michael Catanzaro who helped a lot with making the BoF a success.

¹ BoF: Usually a discussion group on a particular topic at a conference. See for example IETF BoFs.

Apps: Attempt of a status report

This is not an official post from GNOME Foundation nor am I part of the GNOME Foundation’s Board that is responsible for the policies mentioned in this post. However, I wanted to sum up the current situation as I understand it to let you know what is currently happening around app policies.

Core and Circle

Ideas for (re)organizing GNOME apps have been around for a long time, like with this initiative from 2018. In May 2020, the Board of Directors brought forward the concept of differentiating “official GNOME software” and “GNOME Circle.” One month later the board settled on the GNOME Foundation’s software policy. GNOME Circle was officially launched in November 2020.

With this, there are two categories of software:

1. Official GNOME software, curated by the release team. This software can use the GNOME brand, the org.gnome app id prefix, and can identify the developers as GNOME. Internally the release team refers to official software as core.
2. GNOME Circle, curated by the Circle committee. This software is not official GNOME software and cannot use the GNOME trademarks. Projects receive hosting benefits and promotion.

Substantial contribution to the software of either of those categories makes contributors eligible for GNOME Foundation membership.

Those two categories are currently the only ones that exist for apps in GNOME.

Current Status and Outlook

Since the launch of GNOME Circle, no less than 42 apps have joined the project. With Apps for GNOME, we have an up-to-date representation of all apps in GNOME. And more projects benefitting from this structure are under development. Combined with other efforts like libadwaita, new developer docs, and a new HIG, I think we have seen an incredible boost in app quality and development productivity.

Naturally, there remain open issues after such a huge change. App criteria and workflows have to be adapted after collecting our first experiences. We need more clarification on what a “Core” app means to the project. And last but not least, I think we can do better with communicating about these changes.

Hopefully, at the upcoming GUADEC 2022 we will be able to add some cornerstones to get started with addressing the outstanding issues and continue this successful path. If you want to get engaged or have questions, please let me know. Maybe, some questions can already be answered below :)

Frequent Questions

Why is this my favorite app missing?

I often get questions about why an app is absent from apps.gnome.org. The answer is usually, that the app just never applied to Circle. So if your favorite app is missing, you may want to ask them to apply to GNOME Circle.

What do the “/World” and “/GNOME” GitLab namespaces mean?

I often get asked why an app is not on apps.gnome.org or part of “Core” while its repository resides in /GNOME. However, there is no specific meaning to /GNOME. It’s mostly a historical category and many of the projects in /GNOME have no specific status inside the project. By the way, many GNOME Circle projects are not even hosted on GNOME’s GitLab instance.

New “Core” apps however will be moved to /GNOME.

But I can still use org.gnome in my app id or GNOME as part of my app name?

To be very clear: No. If you are not part of “Core” (Official GNOME software) you can’t. As far as I can see, we won’t require apps to change their app id if they have used it before July 2020.

What about those GNOME games?

We have a bunch of nice little games that were developed within the GNOME project (and that largely also still carry legacy GNOME branding.) None of them currently have an official status. At the moment, no rules exclude games from becoming part of GNOME Circle. However, most of those games would probably need an overhaul before being eligible. I hope we can take care of them soon. Let me know if you want to help.