Update on what happened across the GNOME project in the week from December 20 to December 27.

GNOME Core Apps and Libraries

Image Viewer (Loupe)

Browse through images and inspect their metadata.

Sophie 🏳️‍🌈 🏳️‍⚧️ (she/her) announces

Image editing including crop, rotate, and flip has been merged into Loupe. Currently, only PNG images are supported. Support for JPEGs is in the works . There is a list of open issues for the current implementation. You can support my work financially on several platforms .

Third Party Projects

Sebastian Wiesner says

A new release of TurnOn is available. The new release adds network scanning: When scanning is on TurnOn now finds devices in the local network and offers to save them so that it can later turn them on.

TurnOn is a small GNOME utility to turn on remote systems such as NAS devices with Wake On LAN. It’s available from Flathub .

Vladimir Kosolapov says

Netsleuth 1.1.0 is here! This update introduces a search provider for GNOME Shell, command-line interface and new calculable values.

The calculation history now stores up to 20 entries, allowing for quick retrieval of specific IP addresses directly from the GNOME Shell search.

For those who prefer a console experience, the command-line interface enables performing the same calculations as in the graphical version.

This update also introduces two new calculable values — “IPv4 Mapped Address” and “6to4 Prefix”.

Check it out on Flathub !

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

🎶 Vive le vent ! Vive le vent ! Vive le vent d’hiver ! 🌲 And vive Fractal 10.beta! While everyone is resting for the holidays, we thought you could use a new release. It focuses on improvements and bug fixes, including:

• Videos were often not playing after loading in the room history, this was fixed, and we also show properly when an error occurred.
• Computing the size of media messages was slightly wrong, which meant that sometimes a grey line would appear below them. We rebooted the code and that problem is gone!
• Our CSS file was a bit too big for our taste, so we decided to make use of SASS and split it.
• We were downloading too many different sizes for avatar images, which would fill the media cache needlessly. We now only download a couple of sizes. This has the extra benefit of fixing blurry or missing thumbnails in notifications.

As usual, this release includes other improvements, fixes and new translations thanks to all our contributors, and our upstream projects.

It is available to install via Flathub Beta, see the instructions in our README .

As the version implies, there might be a slight risk of regressions, but it should be mostly stable. If all goes well the next step is the release candidate!

If you have a little bit of time on your hands, you can try to fix one of our newcomers issues . Anyone can make Fractal better!

GNOME Websites

Felix announces

Thanks to Brage Fuglseth (he/him), thisweek.gnome.org now supports the OpenGraph protocol , which means you can now get rich social media preview cards on sites that support it (e.g. Mastodon, Discourse, Reddit).

That’s all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

Hi everyone!

It’s been about two weeks since UbuCon Asia (Ubuntu Conference Asia) concluded (fun fact: 13 weeks since I wrote the initial draft, so 15 now), and I’m really starting to miss it.

This blog is being posted after my GNOME Asia post as it was really hard to pack all the emotions and memories in just one blog, but here we go.

It all started as a wild idea to host GNOME Asia a year or two back. Gradually, it transformed into a joint event between UbuCon and GNOME Asia and eventually into UbuCon Asia 2024.

Why Jaipur?

This was one of the most frequently asked questions throughout the conference.

Interestingly, the local team (us) wasn’t based in Jaipur. We were spread across India, with me in the Delhi area, some members in Maharashtra, and one in Karnataka. Managing Jaipur’s affairs, as you can imagine, wasn’t exactly a breeze.

So why did we choose it? When the initial idea came up, a friend and I ruled out cities that were overcrowded, too hot (we weren’t entirely right there, but rain saved us lol), or lacking in the cultural heritage we wanted to showcase. We also wanted to pick a city with a budding tech scene, rather than an established one.

After much deliberation, we ruled out Bengaluru, Delhi, Mumbai, and Hyderabad. Jaipur, being relatively closer to me and ticking all the right boxes, became the chosen one!

In the end, we found the best college we could have in Jaipur, with a phenomenal volunteer team.

Why did we organize it?

Initially, the plan was to host GNOME Asia because GNOME is a community I deeply love. Having attended many GNOME events, I always wondered, "What if we host one in India?" With the largest population, immense Git activity, and a mature tech audience, India seemed perfect. But the sheer effort required always held me back - I’m just a developer who loves to code more than to manage people :)

The UbuCon planning began after GUADEC 2023, where I met Mauro at the Canonical booth. This led to rebooting Ubuntu India, with hosting UbuCon Asia as our first official activity.

I hesitated when asked to host UbuCon Asia but couldn’t resist the challenge. Bhavani (my co-lead) also proposed hosting in Bangalore, so we combined our bid with my proposal for Jaipur. To our delight, we won! Although discussions for a joint venture with the GNOME team didn’t pan out, we forged ahead with UbuCon Asia.

The Challenges We Faced

Although my role was initially to oversee and allocate tasks, I found myself involved in everything, which was hectic. Thankfully, the whole team worked as one on event days and without them, I wouldn’t have been able to handle the last two days of the event.

Managing Jaipur’s affairs remotely was tough, but the college we partnered with was incredibly supportive. Their students volunteered tirelessly.

Unexpectedly, our stage hosts backed out of the event just a day before due to placement drive in college, causing a session delay on the first day. Visa letter delays (Caused due to the Bangladesh crisis) and funding challenges due to Indian remittance laws were additional hurdles.

How It All Ended

Despite everything, we pulled it off, and dare I say, even better than many seasoned organizers might have! Seeing the community gather in India for UbuCon Asia was amazing.

We had Ubuntu and CDAC booths, delicious food (thanks to FOSS United and OnlyOffice), and lots of goodies for attendees. A proper Indian lunch with dessert, coffee breaks with Rajasthani and Indian snacks, a conference dinner, and subsidized day trips - all funded, were a relief.

Considering just weeks ago we were struggling to break even and were partially at a loss, to end with a surplus instead was truly relieving.

Fun fact: Leftover funds helped us host the release party at GNOME Asia 2024 and will support UbuCon India 2025 and UbuCon Asia 2025.

In my opening note, I joked, “I’m excited for the conference to end,” but now I realize how wrong I was.

I enjoyed every moment of it. I wasn’t able to attend more than one talk because when you are the lead, you just can’t sit, you have to work the hardest and keep everything together, but that work also gave me lots of enjoyment and satisfaction.

My favorite feedback? “We knew it was your first time organizing at this scale because we saw how tense and hardworking you were, ensuring everything ran smoothly, which it did.”

I regret not being able to meet many people I wanted to in more depth. Like Debian India folks, Aaditya Soni from AWS Rajasthan, Vishal Arya from FOSS United, Rudra the reviver of Ubuntu Unity and more.

We truly had astonishing people attend and I just wish to re-witness it all from an attendee's perspective now :P

The aftermovie can be viewed at - https://youtu.be/Ul8DQh3yroo?si=U2F3wi6mKBIVPJ6g :D

Future Plans?

Well... UCA’24 was draining and I don’t want to think of another event for a while haha (This didn't last long considering the release party we hosted xD).

We are currently working on creating smaller regional Ubuntu communities in India, and hopefully organise UbuCon India.

So if you are a sponsor, please reach out, we can really use your help in the initiative :)

Also, if you want to be a part of the Ubuntu India LoCo community, let me know and we can have a conversation about it ;)

A special thanks to Canonical, CDAC, FOSS United, Only Office and Ubuntu Korea for their sponsorship :)

I have just released version 0.14 of CapyPDF . This release has a ton of new functionality. So much, in fact, that I don't even remember them all. The reason for this is that it is actually starting to see real world usage, specifically as the new color managed PDF exporter for Inkscape . It has required a lot of refactoring work in the color code of Inkscape proper. This work has been done mostly by Doctormo, who has several videos on the issue.

The development cycle has consisted mostly of him reporting missing features like "specifying page labels is not supported", "patterns can be used for fill, but not for stroke" and "loading CMYK TIFF images with embedded color profiles does not work" and me then implementing said features or finding out how how setjmp/longjmp actually works and debugging corrupted stack traces when it doesn't.

Major change coming in the next version

The API for CapyPDF is not stable, but in the next release it will be extra unstable. The reason is C strings. Null terminated UTF-8 strings are a natural text format for PDF, as strings in PDF must not contain the zero glyph. Thus there are many functions like this in the public C API:

void do_something(const char *text);

This works and is simple, but there is a common use case it can't handle. All strings must be zero terminated so you can't point to a middle of an existing buffer, because it is not guaranteed to be zero terminated. Thus you always have to make a copy of the text you want to pass. In other words this means that you can't use C++'s string_view (or any equivalent string) as a source of text data. The public API should support this use case.

Is this premature optimization? Maybe. But is is also a usability issue as string views seem to be fairly common nowadays. There does not seem to be a perfect solution, but the best one I managed to crib seems to be to do this:

void do_something(const char *text, int32_t len_or_negative);

If the last argument is positive, use it as the length of the buffer. If i is negative then treat the char data as a zero terminated plain string. This requires changing all functions that take strings and makes the API more unpleasant to use.

If someone has an idea for a better API, do post a comment here.

Prerequisite

I have been an Outreachy GNOME intern for a while now. GNOME is a free and open-source desktop environment for Linux and similar systems. It consists of quite a number of projects that make up the entire overall system, and the one I am working on for my internship is Librsvg .

About Librsvg : It is a small library to render Scalable Vector Graphics (SVGs) associated with GNOME projects.

Struggles

Initially, my struggle was with the programming language because Rust wasn’t my primary language before I started the internship. This led to the struggle of understanding the codebase. But let’s be honest, it’s written in Rust, and it takes quite some time to fully onboard. Luckily, my internship is centered around implementations to handle the SVG2 text layout algorithm. Plus, a programming language is just a tool to get the job done and should not be a hindrance if you are willing to learn and put in the work.

During the course of the internship, I have also struggled with some domain-specific terminologies like Bi-di, glyphs, and how the existing program handles SVGs such as nested Bi-di and rendering. The struggle of understanding domain terminologies and how the program executes is natural. The steps to overcoming those struggles are crucial for growth and development.

What stood out towards helping me understand these struggles is the guidance of my mentor, Federico. We set up regular meetings, and whatever is discussed is noted in our shared pad for future reference and documentation. He also made it easy for me to ask questions by making it clear that “no question is too dumb to ask,” and he never takes offense when I re-ask a question he has already answered and I forgot.

In our last meeting, he said something that stuck with me. When I told him a particular task felt overwhelming, he said, “I understand you; it is expected to be overwhelming to anyone,” with a big smile. His understanding and patience have been instrumental in my progress and Federico’s encouragement to ask any question, no matter how small, has been invaluable in building my confidence.

Tackling Tasks

I have completed a few tasks, and the way I approach them is by tackling them head-on. I do research where required and push for review. Never underestimate the power of reviews toward the completion of a project.

Overall, keep an open mind, be ready to learn, and always ask questions. If you have bad memory like mine, write things down as they come.

Final Thoughts

Keep in mind that struggles are part of the journey. You cannot run or shy away from what needs to be done, so why not just do it in time and have the rest of the time to understand your mistakes, reiterate on them, overcome them, and tag it as a win for yourself and a story to share with others.

Looking forward to sharing more of my internship progress with you soon!

See you in the next chapter—cheers!

Not all of my projects this December are code related. In fact a lot of them have been house maintenance things, joy of home ownership and all.

This week was spent building my new office and music space. I wanted a way to have my amplifiers and guitars more accessible while also creating a sort of “dark academia” sort of feeling for working.

The first step was to get the guitars mounted on the walls. I was looking for something blending artistic showpiece and functional use.

After that I quickly framed them in. Just quarter round with the hard edge inwards, 45° miter, some caulking, easy peasy.

My last office had Hale Navy as the color, but the sheen was too much that it made it difficult to actually see the color. This time I went flat and color drenched the space (so ceilings, trim, etc all in matching tone).

Then somewhat final result is here. I still want to have a lighting story for these that doesn’t involve a battery so some electrical fish taping is likely in my future.

I also converted the wide closet into a workstation area with the studio monitors for recording. But that is still partially finished as I need to plane all the slats for the slat wall, frame the builtin, and attach the countertop.

In late June 2024 I got asked to take over the work started by Jerry Wu creating a systemd-sysupdate plugin for Software . The goal was to allow Software to update sysupdate targets, such as base system images or system extension images , all while respecting the user’s preferences such as whether to download updates on metered connections. To do so, the plugin communicates with the systemd-sysupdated daemon via its org.freedesktop.sysupdate1 D-Bus interface.

I didn’t know many of the things required to complete this project and it’s been a lot to chew in one bite for me, hence how long it took to complete. I’m happy it’s finally done, but I’m certain it’s riddled with bugs despite my best efforts, and I’m not happy it’s a single gigantic C file. It needs to be split into modules, but that’s an effort for another time as getting it to work at all was a challenge already. I’m happy I learned a lot along the way. Thanks a lot to Codethink , to the GNOME Foundation , to the Sovereign Tech Agency and for sponsoring this work. Thanks a lot to Abderrahim Kitouni , Adrian Vovk , Philip Withnall and all the other persons who helped me complete this project. 🙂

This was one of the last pieces of software needed to complete the migration of GNOME OS from OSTree to sysupdate. While OSTree is great for operating systems, it has a significant drawback: it can’t support SecureBoot because it can’t support Unified Kernel Images, and SecureBoot requires a signed Unified Kernel Image for its chain of trust. While its A/B partitioning system makes sysupdate more storage hungry and less flexible than OSTree, it allows it to support Unified Kernel Images, to sign them, and to be part of SecureBoot’s chain of trust, ensuring the system hasn’t been maliciously tempered. This will make GNOME OS more secure and trustable. Read more of treusted boot from Lennart Poettering .

You should be able to test this plugin in GNOME OS soon. Please report any issues with the systemd-sysupdate tag, and the GNOME OS one if relevant. We want to be very sure that this works, as it’s vital that users know whether or not their system is up to date, especially if there are security-related fixes involved.

In line with traditions, it's time for the yearly end-of-the year Maps blog post!

There's been some quite nice happenings this year when it comes to Maps (and the underlaying libshumate, our map widget library).

Vector Map Enabled by Default

The biggest change, by large that's happened in 2024 is that we finally did the switch to client-side rendered vector tiles with all the benefits this brings us:

• A “GNOME-themed” map style
• Properly support dark mode
• Localized labels for places (countries, towns, and so on…)
• POI icons can now be directly clicked on the map, bringing up information of place
  

More Use of Modern libadwaita Widgets

Works has continued replacing the old deprecated GtkDialog instances, instead using libadwaita's new dialogs, which also has the benefit of being adaptive for small screen sizes. Right now the only remaining instance of the old dialog type is the sharing “Send to” dialog.

Since the 47 release, the OSM POI editing dialog has received a refreshed look-and-feel based on Adwaita widgets, designed by Brage Fuglseth, and initial draft implementation by Felipe Kinoshita.

More Visual Improvements

Also since the September release, some more UI refinements have been made.

The action of starring a place now has an accopanying animation to help give a visual clue of the change.

The headerbar icon for showing the menu listing stored favorites now uses the same icon as GNOME Web (Epiphany), the “books on a libray shelf“ icon.

Spinner widgets (for showing progress) has been updated to the new Adwaita variant with a refreshed design.

And the toggle buttons for selecting routing mode (walk, bike, car, transit) now uses the new Adwaita ToggleGroup icon buttons.

Public Transit Routing Using Transitous

I have mentioned the Transitous previously and since 47.0 Maps uses Transitous to provide public transit directions for regions that weren't already covered by our existing plugins and their provided regions.

During the last few months works has progressed on an updated version of MOTIS (the backend used by Transious) that will give better performance, among otheres.

Maps will also soon transition to the new API when Transitous switches over to it.

And speaking of Transitous and MOTIS.

At FOSDEM 2025 me, Felix Gündling, and Jonah Brüchert will give a presentation of MOTIS, Transitous, and the integration into Maps.

https://fosdem.org/2025/schedule/event/fosdem-2025-4105-gnome-maps-meets-transitous-meets-motis/

And until next time, happy holidays!

Lately I’ve been working on touch controls overlays in Highscore ¹ , and quickly found out that previewing them across different screen sizes is rather tedious.

Currently we have two ways of testing UIs on a different screen size – resize the window, or run the app on that device. Generally when developing, I do the former since it’s faster, but what dimensions do I resize to?

HIG lists the 360×294px dimensions, but that’s the smallest total size – we can’t really figure out the actual sizes in portrait and landscape with this. Sure, we can look up the phone sizes, check their scale factor, and measure the precise panel sizes from screenshots, but that takes time and that’s a lot of values to figure out. I did make such a list , and that’s what I used for testing here, but, well, that’s a lot of values. I also discovered the 294px height listed in HIG is slightly wrong (presumably it was based on phosh mockups, or a really old version) and with older phosh versions the app gets 288px of height, while with newer versions with a slimmer bottom bar it gets 313px.

Now that we know the dimensions, the testing process consists of repeatedly resizing the window to a few specific configurations. I have 31 different overlay, each with 7 different layouts for different screen sizes. Resizing the window for each of them gets old fast , and I really wished I had a tool to make that easier. So, I made one.

This is not a separate app, instead it’s a libadwaita feature called adaptive preview, exposed via GTK inspector. When enabled, it shrinks the window contents into a small box and exposes UI for controlling its size: specifically, picking the device and shell from a list. Basically, same as what web browsers have in their inspector – responsive design mode in Firefox etc.

It also allows to toggle whether window controls are visible – normally they are disabled on mobile, but mobile gnome-shell currently keeps them enabled as not everything is using AdwDialog yet.

It can also be opened automatically by specifying the ADW_DEBUG_ADAPTIVE_PREVIEW=1 environment variable. This may be useful if e.g. Builder wants to include it into its run menu, similar to opening GTK inspector.

If the selected size is too large and doesn’t fit into the window, it scrolls instead.

What it doesn’t do

It doesn’t simulate fullscreen. Fullscreen is complicated because in addition to hiding shell panels almost every app that supports it changes the UI state – this is not something we can automatically support.

It also doesn’t simulate different scale factors – it’s basically impossible to do with with how it’s implemented.

Similarly, while it does allow to hide the window controls, if the app is checking them manually via GtkSettings:gtk-decoration-layout , it won’t pick that up. It can only affect AdwHeaderBar , similarly to how it’s hiding close button on the sidebars.

Future plans

It would be good to display the rounded corners and cutouts on top of the preview. For example, the phone I use for testing has both rounded corners and a notch, and we don’t have system-wide support for insets or safe area just yet. I know the notch dimensions on my specific phone (approximately 28 logical pixels in height), but obviously it will vary wildly depending on the device. The display panel data from gmobile may be a good fit here.

We may also want to optionally scale the viewport to fit into the window instead of scrolling it – especially for larger sizes. If we have scaling, it may also be good to have a way to make it match the device’s DPI.

Finally, having more device presets in there would be good – currently I only included the devices I was testing the overlays for.

---

Adaptive preview has already landed in the main branch and is available to apps using the nightly SDK, as well as in GNOME OS.

So, hopefully testing layouts on mobile devices will be easier now. It’s too late for me, but maybe the next person testing their app will benefit from it.

---

1. gnome-games successor, which really deserves a blog post of its own, but I want to actually have something I can release first, so I will formally announce it then. For now, I’m frequently posting development progress on the Fediverse

Two weeks ago we got together in Berlin for another (Un)boiling The Ocean event (slight name change because Mastodon does not deal well with metaphors). This time it was laser-focused on local-first sync , i.e. software that can move seamlessly between real-time collaboration when there’s a network connection, and working offline when there is no connection.

The New p2panda

This event was the next step in our ongoing collaboration with the p2panda project . p2panda provides building blocks for local-first software and is spearheaded by Andreas Dzialocha and Sam Andreae . Since our initial discussions in late 2023 they made a number of structural changes to p2panda, making it more modular and easier to use for cases like ours, i.e. native GNOME apps.

Sam and Andreas introducing the new p2panda release.

This new version of p2panda shipped a few weeks ago, in the form of a dozen separate Rust crates, along with a new website and new documentation.

On Saturday night we had a little Xmas-themed release party for the new p2panda version, with food, Glühwein, and two talks from Eileen Wagner (on peer-to-peer UX patterns ) and Sarah Grant (on radio communication).

The Hackfest

Earlier on Saturday and then all day Sunday we had a very focused and productive hackfest to finally put all the pieces together and build our long-planned prototype codenamed “Aardvark”, a local-first collaborative text editor using the p2panda stack.

Simplified diagram of the overall architecture, with the GTK frontend, Automerge for CRDTs, and p2panda for networking.

Our goal was to put together a simple Rust GTK starter project with a TextView, read/write the TextView’s content in and out of an Automerge CRDT, and sync it with other local peers via p2panda running in a separate thread. Long story short: we pulled it off! By the end of the hackfest we had basic collaborative editing working on the local network (modulo some bugs across the stack). It’s of course still a long road from there to an actual releasable app, but it was a great start.

The reason why we went with a text editor is not because it’s the easiest thing to do — freeform text is actually one of the more difficult types of CRDT . However, we felt that in order to get momentum around this project it needs to be something that we ourselves will actually use every day. Hence, the concrete use case we wanted to target was replacing Hedgedoc for taking notes at meetings (particularly useful when having meetings at offline , where there’s no internet).

The current state of Aardvark: Half of the UI isn’t hooked up to anything yet, and it only sort of works on the local network :)

While the Berlin gang was hacking on the text editor, we also had Ada , a remote participant, looking into what it would take to do collaborative sketching in Rnote . This work is still in the investigation stage, but we’re hopeful that it will get somewhere as a second experiment with this stack.

Thanks to everyone who attended the hackfest, in particular Andreas for doing most of the organizing, and Sam Andreae and Sebastian Wick, who came to Berlin specifically for the event! Thanks also to Weise7 for hosting us, and offline for hosting the release party.

The Long Game

Since it’s early days for all of this stuff, we feel that it’s currently best to experiment with this technology in the context of a specific vertically integrated app. This makes it easy to iterate across the entire stack while learning how best to fit together various pieces.

However, we’re hoping that eventually we’ll settle on a standard architecture that will work for many types of apps, at which point parts of this could be split out into a system service of some kind. We could then perhaps also have standard APIs for signaling servers (sometimes needed for peers to find each other) and “dumb pipe” sync/caching servers that only move around encrypted packets (needed in case none of the other peers are online). With this there could be many different interchangeable sync server providers, making app development fully independent of any specific provider.

Martin Kleppmann’s talk at Local-First Conf 2024 outlines his vision for an ecosystem of local-first apps which all use the same standard sync protocol and can thus share sync services, or sync peer-to-peer.

This is all still pretty far out, but we imagine a world where as an app developer the only thing you need to do to build real-time collaboration is to integrate a CRDT for your data, and use the standard system API for the sync service to find peers and send/receive data.

With this in place it should be (almost) as easy to build apps with seamless local-first collaboration as it is to build apps using only the local file system.

Next Steps

It’s still early days for Aardvark, but so far everyone’s very excited about it and development has been going strong since the hackfest. We’re hoping to keep this momentum going into next year, and build the app into a more full-fledged Hedgedoc replacement as part of p2panda’s NGI project by next summer.

That said, we see the main value of this project not in the app itself, but rather the possibility for our community to experiment with local-first patterns, in order to create capacity to do this in more apps across our ecosystem. As part of that effort we’re also interested in working with other app developers on integration in their apps, making bindings for other languages, and working on shared UI patterns for common local-first user flows such as adding peers, showing network status, etc.

If you’d like to get involved, e.g. by contributing to Aardvark, or trying local-first sync in your own app using this stack feel free to reach out on Matrix (aardvark:gnome.org), or the Aardvark repo on Github .

Happy hacking!