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.
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.
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.
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 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.
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?
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.
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.
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 smalleradditions. We also discussed future GTK APIs for HDR images and ICC profiles in a call. Libadwaita also got some featuresneeded for Loupe. The image decoding crates got a bunch of commits to add support for ICCcolormanagementprofiles. For the libheif bindings, the maintainer took care of most of the neededchanges.
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.
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.
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.
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.
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.
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.
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 :)
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 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.
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.
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!
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 :)
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:
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:
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:
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.