Sophie Herold – Page 2 – Sophie's Blog

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.