GNOME – Sophie's Blog

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.

Pika Backup 0.4 Released with Schedule Support

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

Pika Backup version 0.4 has been released today. This release wraps up a year of development work. After the huge jump to supporting scheduled backups and moving to GTK 4 and Libadwaita, I am planning to go back to slightly more frequent and smaller releases. At the same time, well-tested and reliable releases will remain a priority of the project.

Release Overview

The release contains 41 resolved issues, 27 changelog entries, and a codebase that despite many cleanups nearly doubled. Here is a short rundown of the changes.

- - Ability to schedule regular backups.
  - Support for deleting old archives.
  - Revamped graphical interface including a new app icon.
  - Better compression and performance for backups.
  - Several smaller issues rectified.

You can find a more complete list of changes in Pika’s Changelog.

Thanks!

Pika Backup’s backbone is the BorgBackup software. If you want to support them you can check out their funding page. The money will be well spent.

A huge thank you to everyone who helped with this release. Especially Alexander, Fina, Zander, but also everyone else, the borg maintainers, the translators, the beta testers, people who reported issues or contributed ideas, and last but not least, all the people that gave me so much positive and encouraging feedback!

Resources

“apps.gnome.org” is Online!

Our Apps for GNOME website is now available at apps.gnome.org! It features the best applications in the GNOME ecosystem. Let’s quickly get into the most exciting aspects of Apps for GNOME.

- Focus on participation. The app pages are designed with a focus on getting users involved in the development of the application. Whether it is feedback, translation, or financial support of the project. Apps for GNOME offers a lot of ways to get involved in app development.
- Internationalization. This website is the first source that provides translated information about apps in the GNOME ecosystem. This is another small step towards lowering the barrier for getting into using and contributing to GNOME.
- Up-to-date information. Apps for GNOME almost exclusively relies on existing metadata that, for example, are used in Software or on Flathub. Therefore it does not require extra work for app maintainers to keep information up-to-date. Better yet, Apps for GNOME is an additional incentive for maintainers and translators to optimize and translate that information.
- Featuring apps that don’t fit on Flathub. It’s not technically feasible to distribute apps like Software, Files, or Terminal on Flathub. Apps for GNOME gives those apps the web presence they are missing out on Flathub.

We certainly hope to extend those aspects in the future as this announcement only concludes a rapid development cycle of fewer than eight weeks from the first idea until today. We are looking forward to your feedback, and ideas, and contributions to this project!

If you are interested in some background information you can check out my previous blog posts. Let’s conclude with an attempt to catch up with acknowledgments: Kind thanks to Bilal and Felix for providing an AppStream library and libflatpak bindings for rust. Thanks also to all the translators that make such internationalized project possible in the first place. Last but not least, a huge shoutout to Andrea and the rest of the infrastructure team for the prompt support in realizing this project and keeping GNOME online. You folks are the best :)

Get set: Apps for GNOME on its mark

A week ago I proposed an “Apps for GNOME” website. After quite some positive feedback and some more tweaks, we are pretty close to launching the first version. If you are not happy with how your app looks on the page or you want to help with optimizing “Apps for GNOME” here are a few things that you can do. If you have any further questions, ideas, or just want to complain about the writing style of this post feel free to ping me anywhere you can find me or to just drop me an issue.

Available for translation

Almost all strings in Apps for GNOME are translatable now. You can check the apps-for-gnome module translation status over at Damned Lies. Be aware, that all app-specific strings will not appear in the apps-for-gnome module! Most apps have their own module in Damned Lies where you will find the respective strings that are used on the Apps for GNOME page. If you want to work on the translation of those app details, you have to consult the respective app module. Also note, that some apps do not use the GNOME translation infrastructure.

Make it short and crisp

The text that gets below the app name is called “summary” in the metadata. The upcoming version of Software expects this to be a snappy description of your app. And so does Apps for GNOME. The guidelines for metadata are not finalized but if you want your app to look good we currently recommend the following: Keep it short – 35 characters or less. Pique people’s curiosity. Use imperative if possible (e.g. “Browse the web” instead of “A web browser”). And finally, avoid technical details and environment designations like “for GNOME.”

Finding your color balance

Like Software I’m trying to extract a neat color scheme for your app from the app icon. While even a broken clock is right twice a day that still leaves us with a lot of apps where the silly algorithm gives us an ugly color scheme or one that looks bad with the app icon on top of it. However, you are the person that can decide your app’s fate … and color scheme. ~~You just have to add, at least two, colors to your metadata.xml like that:~~

<custom>
  <value key="GnomeSoftware::key-colors">[(124, 53, 77), (99, 16, 0)]</value>
</custom>

The interpretation of Software might be different, but Apps for GNOME uses the first value as primary (background) color and one of the other entries as secondary (text) color. You can find those two colors as CSS variables on the app page if you want to try out your new colors with your browser’s inspector first.

~~By the way, if you are happy with the colors for your app, you don’t have to add this key to your metadata.~~

Update: The previous explanation of key-colors conflicted with the way Software uses them. Please use the instructions on the Software Wiki instead!

Want to show your face?

The “Get to know us” section uses data from your GitLab account. See below for more details. If you are a maintainer and want to show some information about you in this section, maybe it’s time to update your GitLab profile and upload a nice photo of yours.

Speaking of photos: While this might contradict the appstream docs, please do include the window shadows in your screenshots.

Maintainers are dope

DOAP files are quite neat for multiple reasons. They make your App show up with the defined name in Builder. Inside the GNOME GitLab group, they even manage repository access for maintainers. And in Apps for GNOME they determine who shows up in the “Get to know us” section. GNOME Core apps should be all set since a .doap-file is mandatory for them. GNOME Circle maintainers however should pay attention now!

If you don’t have a .doap-file in your repository, you should really consider creating one right now. Otherwise, the “Get to know us” section won’t appear on your app’s page. And adding a .doap-file it’s quite simple too! You just have to ensure that the file name equals the project’s GitLab (and in the future possibly GitHub) path. For example, if your app lives in World/my-app you need a my-app.doap file in your git repo’s root. You can probably just copy a random existing .doap-file to get started. But, watch out one more time!

The traditional .doap-files in GNOME use a “gnomeid” to identify maintainers. This mysterious token is mostly reserved for GNOME Foundation members and it also involves some trickery to link it to GitLab accounts. Therefore, we decided that outside of the GNOME GitLab group we will use a different method to link maintainers to GitLab accounts. And this method looks like this:

<foaf:account>
  <foaf:OnlineAccount>
    <foaf:accountServiceHomepage rdf:resource="https://gitlab.gnome.org"/>
    <foaf:accountName>sophie-h</foaf:accountName>
  </foaf:OnlineAccount>
</foaf:account>

This format is a bit involved for defining two keys but, I think you will get the hang of it and hey, it uses an existing standard! All hail the two-thousands and its dream of the semantic web! You can have a look at this real-world example if you are still confused.

Where even is your repository?

Actually, our page generator is starting from a list of app ids. There is no certain way to know what your app’s repository is. We have to guess. And the safest way to ensure that we find your repository is to add a proper URL for your bug tracker to the metadata. This would look something like this:

<url type="bugtracker">https://gitlab.gnome.org/World/decoder/-/issues</url>

That’s it for today …

There are so many aspects to Apps for GNOME that we cannot possibly aim for having every detail perfected for the launch. But I am already quite happy with the current state. Stay tuned for more updates though and let me know if you want to get involved.

An “Apps for GNOME” website

TL;DR: Something like an “Apps for GNOME” website might exist pretty soon. This changes nothing about existing pages. You can have a look at the current state of the website. Feedback and contributions are more than welcome.

Currently, most apps in the GNOME ecosystem are represented by a wiki page or README at our GitLab instance. All the information in these wiki pages has to be updated manually in parallel to the other sources like the AppStream MetaInfo file, the screenshots, or the DOAP file. I was no longer motivated to do this work manually for my app and started looking for alternative solutions. I quickly wrote a small script that generates an app page. After showing the generated page around, several people proposed to provide such app pages in a centralized fashion for GNOME.

What app pages could provide

Having a standardized page for apps could provide a bunch of useful information to users and contributors. My main focus is less about technical information but more about how to get engaged, how to fill an issue or how to get in touch with the community around an app. Introducing the people that are involved in the app’s development could help to build up an emotional connection to the app and in the end maybe incentivize users to contribute their time or money to the project.

In contrast to the Flathub pages, a GNOME specific apps website could not only emphasize slightly different aspects of an app. Rather, a separate website would also allow us to provide a GNOME specific curated list of apps. This would make it easier for people to search for apps that are suitable for their desktops.

Apart from that, there are a bunch of apps that will not be available via Flathub for technical reasons (e.g. Settings, Terminal, Files) in the foreseeable future. If we could integrate them in these app pages as well they might profit from more visibility as a project.

One last thing that this project could maybe rectify is that neither our wiki nor the Flathub pages currently provide translated app information. In practice, this means, if you are searching the web for a GNOME app you probably only have a chance of reaching a somewhat “official” landing page for an app if you searching in English. As Shaun McCance has recently outlined in his GUADEC talk about documentation, online search is something that we should cover if possible. Notably, translations for AppStream MetaInfo are available in GNOME Software. However, currently, the data is hardly accessible anywhere else.

A sled dog makes an attempt

As it turns out, I’m not the first person with the idea to automatically generate pages for apps in GNOME. However, as far as I know, nobody has tried it yet. But so far, it does not look like an impossible feat. Meet “codename malamute.”

Malamute starts by collecting a list of all the core and GNOME Circle apps from their official lists. Next, it uses the pre-build metainfo file from Flathub to obtain the metadata, including translations, for every app. Those data are, for example, supplemented by the maintainers’ GitLab profile information. This data is fed into tera, a Jinja2-like template engine. Within less than one minute run time – and by passing over the rust compile time – we end up with about 150 MB of static page data.

What’s next

I already received some early feedback on the project. A small number of real-world tests seem to suggest that the page in it’s current form could already be of use for GNOME users. For example by making them aware of the number of useful apps that suddenly appeared as part of GNOME Circle.

The purpose of this post is mainly to reach out for broader feedback. I don’t have any conflicts with existing infrastructure on my radar, but please let me know if I am overlooking something. Maintainers can still decide to keep their app wiki pages or to role individual pages in parallel to this project. They can be (and mostly already are) linked from the apps detail page.

A topic I personally feel very uncertain about is reusing personal data from GitLab or GitHub user profiles. In theory, all those data are public, but they are presented in a different context on app pages. It might even be legally required for people to opt-in to this feature. It would be much appreciated if someone could help me with this question.

There are a ton of technical details that still need to be implemented. The design team already indicated that they might have some words to say about my attempts at designing those pages ? Another issue is the quality of metadata. I think we should by no means underestimate the quality of the data that already exist! But, this is likely an area that – combined with a shiny new design for Software in GNOME 41 – might gain some new traction.

If you want to give feedback or get involved you can use the issue tracker, hit me up on Rocket.Chat or Matrix or ping me on Twitter. Big thanks to everyone who helped with this project so far, especially Alexandre, Tobias, Zander, and of course everyone I forgot to list here!

PS: To avoid further questions about the codename, the official name will probably change to something more generic in the future.

New gtk-rs release and more

The latest gtk-rs release is officially available since today. The perfect time to explain some of the contributions I made.

Docs, docs, docs …

A huge amount of effort went into documentation for this release. The people working on gtk-rs gir provided huge improvements to the automatically generated docs! I also tried to contribute to those efforts and, among other things, updated the content of the crate landing pages.

Besides the content there was another ongoing problem with docs: For license and technical reasons gtk-rs docs cannot be on docs.rs. That also meant that there was no real solution for handling docs for different versions. While it felt pretty wrong to redo things that docs.rs already does, I created gir-rustdoc. It generates a landing page listing the documentation links for different releases. It ensures that references to gtk-rs crates work and automatically links to the correct version. On GitLab the script collects different doc versions from artifacts and merges them to one GitLab page. And finally, it hacks a warning about outdated and development versions into the documentation pages. I tried ensure that the use of the script needs very little configuration and integrates as seamless as possible. However, I should have created a test repository for GitHub as well before things landed on the gtk-rs repos there. Debugging in CI with a real project usually isn’t fun.

Redesign of gtk-rs.org

What originally started as a small design improvement ended up in a complete redesign of the website. The original website was from the very early days of the project. I’m very happy that we developed the start page into a direction that provides space for many aspects of the gtk-rs projects. These include crates, the GTK 4 in Rust book, related rust bindings like libadwaita-rs and the documentation of gtk-rs gir.

A lot of work went into consolidating documentations, tutorials and examples. I am optimistic that all those efforts will simplify onboarding a lot.

I have not touched web design for many years. Having features like flex-boxes available really simplifies web-design a lot. That was quite a nice experience :)

Rust Handy bindings

Besides updating the Handy bindings to work with the new gtk-rs version I also fixed a bunch of broken links in the documentation and added a basic example. Last but not least, there is now support for Handy 1.2. So the new libhandy-rs 0.8 release is already available and compatible with the latest gtk-rs release!

Beyond Pika Backup 0.3

Pika Backup is an app focused on backups for personal data for the average user. It’s internally based on borg-backup and provides fast incremental backups.

With version 0.3 out of the door, it’s time to look at the future of Pika Backup.

By far the most requested feature is support for scheduled backups. Using borg-backup as backend, even hourly backups should be no problem in many circumstances. If only Pika would support it. While the basic concept for scheduled backups is clear, the devil is in the detail. There is a huge potential for grinding somebody’s gears with a flood of notifications while it’s equally dangerous to let backups silently fail too often. Also, there are metered connections, laptops running on batteries, USB devices that are not connected, people that are traveling and so much more. Therefore, the main task is to find a set of rules for all of these cases with different setups that work well. I also loosely experimented with collecting »user stories« to get some insight into more use cases. This already turned out to be quite valuable while creating some connections with the people that are using Pika Backup. I really liked like the approach so far :)

Another feature that is sorely missing is proper support for recovery. It’s a feature that’s causing me headaches. What if you want to migrate to a new computer and your uid has changed? How to read your data from an ext3 drive? What do we do if the username has changed? Those are very basic and valid use cases but they will probably need some plumbing. However, achieving a recovery dialog that greets you with your Avatar and your old user name, is a goal that keeps me motivated. Just imagine the relief if a user sees a dialog like this after their hard drive failed.