• Mail chew, signed visa papers for another great COOL Days attendee, just under a month to go: exciting.
• Sync with Dave & Laser.
• Published the next strip around resolving apparently irreconcileable differences: "show me the road"
  

07 May 2025 10:50am GMT

I'm usually not a huge fan of personal growth books. As I pointed out in my Blinkist review, most books of this genre are 300 pages long when all the content would fit on 20. I read Deep Work by Cal Newport, with an open but skeptical mind.

A case for deep work

The book is split in two main sections. In the first section, the author makes a case for deep work. He argues that deep work is economically viable because it can help you learn new skills fast, a distinctive trait to successful people in tech, especially when competing with increasingly intelligent machines. This argument is surprisingly timely now, at the peak of the AI bubble.

He then explains that deep work is rare because in the absence of clear indicators of productivity, most people default to appearing very active shuffling things around. This argument clearly resonated with my experience for all my career.

Newport closes the first section by explaining why deep work is actually important for us humans because it limits our exposure to pettiness, makes us empirically happier than shallow work, and because it helps us find meaning to our work.

Rules for deep work

In the second section, the author lays out the four rules to enable deep work:

1. Decide the length of your deep work sessions, establish a ritual for them, keep track of your consistency and hold yourself accountable to it, and refrain from overworking since it decreases your global productivity.
2. Since the Internet can be very distracting, establish some time blocks with Internet and some without, and enforce the rule strictly even if it seems silly.
3. Pick up the right tools for your job by assessing the positive but also the negative impact. Most of the time that means "get off social media." Also avoid fast-paced entertainment since it can undo all the day training and embrace boredom as a way to train your focus.
4. Use every minute of your day intentionally by scheduling them, even if that means redoing your schedule several time as new priorities emerge. Quantify the depth of your work and ask your boss for a shallow work budget. Finish early so your day is tightly time boxed and shallow work becomes even more expensive (so easier to refuse). Become hard to reach so you don't spend your day in your inbox.

An insightful book

Like in all personal growth books, storytelling takes many pages in Deep Work, but here it supports nicely the argument of the author. The book was pleasant to read and helped me question my relationship to technology and work.

In the first section the author backs his claims about the importance of focus with evidences from academic studies. Of course since the second section is all about establishing new rules to allow deep work, it's not possible to have proofs that it works. With that said, I bought a late edition and would have liked an "augmented" conclusion with evidence from people who used the methodology successfully in the real world.

You can find my key takeaways from the book by having a look at my reading notes.

07 May 2025 9:00am GMT

• Up very early, bid 'bye to A & J, breakfast with B. power cut - power restored.
• Planning call, finished mail, tested some tickets, read some code changes.
• Out for lunch into town with J. and B.
• Back for a partner call, sync with Laser, wider partner meeting, admin.
• Dinner with B, call with A, and E. - all well.

06 May 2025 9:00pm GMT

A few months ago, I announced that I was working on a new implementation of Planet GNOME, powered by GitLab Pages. This work has reached a point where we're ready to flip the switch and replace the old Planet website.

You can check it out at planet.gnome.org

This was only possible thanks to various other contributors, such as Jakub Steiner, who did a fantastic job with the design and style, and Alexandre Franke, who helped with various papercuts, ideas, and improvements.

As with any software, there might be regressions and issues. It would be a great help if you report any problems you find at https://gitlab.gnome.org/Teams/Websites/planet.gnome.org/-/issues

If you are subscribed to the old Planet's RSS feed, you don't need to do anything. But if you are subscribed to the Atom feed at https://planet.gnome.org/atom.xml, you will have to switch to the RSS address at https://planet.gnome.org/rss20.xml

Here's to blogs, RSS feeds, and the open web!

06 May 2025 3:46pm GMT

I'm incredibly excited to serve the GNOME Foundation as its new full-time Executive Director.

As Richard mentioned, I am receiving the baton from him, after his tenure as the GNOME Foundation's interim Executive Director. Richard helped guide the Foundation through some rough terrain and, after all that, I'm especially grateful that Richard has been so generous with his time. All the best, Richard. Thank you for everything you do! It always feels good to make a new friend like Richard and I don't think he'll be a stranger to the GNOME community, even once he's neck-deep in his PhD thesis.

It is precisely that community - that global network of friends - that has me so excited to work with the GNOME Foundation. The word "excited" really doesn't do it justice. I have been involved in many free software, open design, and open docs efforts over the years. But none of those have the gargantuan history, community, and installed base of GNOME. It is a privilege to serve GNOME, and I'm grateful. That gratitude is the entire reason I'm here and I'd like to take the rest of this post to explain where that feeling comes from - and what I hope to do with it.

## My story

Since I am new to the GNOME community, I'll start by sharing some background on myself.

I grew up in a village of 1000 people in western Canada and, within that village, I was unquestionably "that computer nerd kid." I built a graphical MUD before the term "MMORPG" was coined. The code was awful. I started my first web development company when I was 15 years old. It was very 1996.

I started a couple more businesses in University, around the time I started using Linux and GNOME: MonoHost, which provided ASP.net webhosting on Linux, and a small software consultancy. Neither of those stuck.

After University, my professional software career can be broken down into two 10-year chunks: pre-crash and post-crash.

The first ten years is a blur. I joined ThoughtWorks when they had fewer than 500 employees, got involved in the early agile (lower-case "a") software movements, used Rails before 1.0, wrote C#, Ruby, Java, JavaScript, and Clojure, joined DRW, built large distributed systems, led teams, got bored, moved to India, and started Nilenso Software with seven friends. Nilenso Software is India's first employee-owned technology cooperative and it still exists today.

Two years into Nilenso, I had a bicycle crash and three botched eye surgeries while visiting a client in California. I was left partly blind. I have a crushed optic nerve, vitrectomy, and scleral buckle. (I suggest… not looking up example videos.)

After the bicycle crash, I found it difficult to code - or even use a computer at all, at certain contrasts. White backgrounds, for example, still cause me instant headaches. And so I began a decade of recruiting, sales, management, startups, fundraising, and product consulting. After leaving Nilenso, I volunteered with nonprofits and worked on two open source database products: XTDB and Endatabas. After closing down Endatabas, I began interviewing with the GNOME Foundation, which brings me here.

I moved back to Canada during Covid and I now live in Halifax, on the east coast. (One timezone east of New York, Europeans will be happy to note!) I still ride bicycles. I run in the park, swim in the ocean, canoe to islands, and climb rocks. I play board games. I write a little code on weekends. I meditate Vipassana. I have an off-grid cabin by the ocean that requires constant repairs. I drive an old truck. Due to an inside joke that went too far, I only wear black suits with white shirts. On any given day, I can smoothly transition between business meetings, weddings, and funerals. As one does.

Over the past three decades, I have been inspired by many open source projects but the aspect of GNOME that inspires me the most is the clarity of its mission. There is never any disagreement about the mission: GNOME is a universal computing environment. It is for everyone, everywhere.

I'm in awe of this.

If you've ever been involved in the creation of a software product, you'll appreciate just how exceptional it is for one product (especially one so large) to retain a single mission like this for a quarter century. That kind of continuity doesn't just magically happen. Let's talk about that for a second.

## Gratitude

Over the past few days, with each conversation I've had with folks in the community, I found myself increasingly grateful for the decades of work put into GNOME. A person forgets just how much time, energy, leadership, and passion has gone into a project of this size.

I've been using GNOME since 2002. By the late 2000s, it was becoming very easy to take GNOME for granted. By GNOME 3, it's safe to say I did take GNOME for granted. This is a good thing, in a way. We take the water utility or electricity in our homes for granted precisely because they work so perfectly and invisibly that their origins can be forgotten.

But GNOME isn't financed by billions of tax dollars. It's easy to forget that, too. My friends and colleagues over the years have compared GNOME to MacOS and Windows, apples-to-apples, as if GNOME were also built by a 3-trillion-dollar corporation. If your open source project is compared favourably to competitors with a $6T aggregate market cap, you're doing something right.

This continuity is magical, but it's magic created by the many contributors who make GNOME happen, release to release, year after year.

I don't want to feel this gratitude alone. As part of our work at the Foundation, I hope we can bring this feeling to many of GNOME's users.

## Transparency

Bringing that feeling to users means showing them the people and processes behind GNOME. None of us can understand infrastructure like GNOME without a window into it. So many of the systems we rely on every day are hidden from us. I have always loved this Hans Rosling comment:

Sometimes, when I turn the water on to wash my face in the morning and warm water comes out just like magic, I silently praise those who made it possible: the plumbers. When I'm in that mode I'm often overwhelmed by the number of opportunities I have to feel grateful to civil servants, nurses, teachers, lawyers, police officers, firefighters, electricians, accountants, and receptionists. These are the people building societies. These are the invisible people working in a web of related services that make up society's institutions. These are the people we should celebrate when things are going well.

The contributors, maintainers, board members, and Foundation staff are these plumbers. Even in my short few days with the Foundation, I've seen everyone working hard behind the scenes to keep the lights on and ensure GNOME 49 will be a success, even if it feels like GNOME 48 was just released moments ago.

I want millions of GNOME users to see what I've had the privilege to see: the life and energy of the folks who keep GNOME running for us.

We should celebrate. We have every reason to.

## Intentions

Of course, transparency isn't a switch we can just turn on. It's a constant effort we apply to our own processes. It's iterative. It's work. But it can also be fun! Knowing that everyone else is trying their hardest can be the most energizing motivation, and I'm excited to help.

Beyond transparency, I hope we can re-establish the GNOME Foundation's … well, foundations. The Foundation exists to support GNOME, to support design and development, to support contributors.

A big part of this is financial stability. Ultimately, the Foundation should support new growth. But to begin with, we need bedrock.

One word to describe these intentions is resilience: across finances, people, documentation, and processes. Let's build an environment that lasts another 27 years.

06 May 2025 11:48am GMT

A few weeks ago I was invited to talk about firmware updates for servers using fwupd/LVFS at Prem'Day 2025. I gave the hardware vendors a really hard time, and got lots of instant feedback from customers in the the audience from the "little green thumbs" that people could raise. The main takeaway from the Prem'Day community seemed to be that proprietary tooling adds complexity without value, and using open ecosystems enable users to better operate their infrastructure.

Since getting back to the UK I've had some really interesting discussions with various companies; there might be some nice announcements soon.

05 May 2025 6:41pm GMT

Recently, Tobias Bernard posted a retrospective of his (and our) experience engaging with the GNOME Foundation regarding the removal of Sonny Piers from our community, followed by a response from Allan Day. I know it's difficult and stressful to talk about; a lot of people just want it to go away. It took a long time to write this.

The details regarding the removal of Sonny Piers will never be publicized, but I respectfully disagree that all discussion of the community impact should happen internally. Regardless of the circumstances at the time, the GNOME Foundation made a decision to publicly remove Sonny Piers from the community and if we are asked to assume good faith, we should be able expect the same good faith when we criticize governance.

# Safety in the Community

The case of Sonny Piers includes GNOME Foundation membership, a seat on the board of directors and employment as a project coordinator. Circumstances these complex do not relate to the Code of Conduct Committee (CoCC) in its typical operation.

The Engagement Team also plays an active role in day-to-day moderation, as well as the community members from diverse backgrounds serving as moderators in the many project channels. Recently a member of the CoCC helped organize a communication channel and new guidelines for moderators, which has already improved coordination and response times across the various platforms.

The GNOME community is a safe place to engage in open source and the matters discussed here should not prevent you from reporting an incident or flagging content for moderation.

CoC Links

• Code of Conduct
• Report an Incident

# Opaque Context

The following is a very incomplete timeline, providing some amount context for my personal perspective.

In July 2024, many of us in the community were shocked to hear that Sonny Piers had been removed as a GNOME Foundation director, stripped of his membership, had all accounts locked and a permanent ban put in place. More unsettling, he was named as the recipient of a Code of Conduct complaint, but obviously without any details regarding the incident.

With such limited information, for many there was little justification to protest the decision itself, except that the degree of disciplinary action implied behaviour extremely out of character for Sonny.

By October, three months had passed and lacking any meaningful resolution, enough concern had grown in parts of the community to have a conversation. It was decided to compose a letter directly to the Board and, after lengthy discussion of the content, those that agreed signed and it was received generally well by the Board.

The resulting meetings were draining for everyone involved, often with visible exertion of good faith from those present. The many constructive results include several amendments to CoCC procedures, more comprehensive and equitable agreements for contractors, and a fair amount of clarification regarding the constraints the Board was under at the time.

By December, I had withdrawn from most social spaces in the community. During the period of engagement with the Board, there were a conspicuous number of public references made to toxic influencers and after a very disappointing comment from a relevant party, I closed my Mastodon account. Aside from compounding the stress of the meetings, I considered I might be compelled to publicly defend Sonny and compromise our efforts with the Board.

In January, Tobias published Re-Decentralizing Development and seeing the reactions include sentiments like "Cult of Sonny" more or less vindicated my decision to withdraw from social spaces. Some clearly assumed there had been no effort to resolve the matter internally and the spectre of a toxic influencer meant attempts to engage publicly were unlikely to be taken in good faith.

# Good Faith

There are legitimate concerns about an effort to undermine the Code of Conduct (CoC), for the sake of meritocracy. In other words, there are those concerned about different rules being applied to those who contribute more substantially or have more social capital. This is not paranoia; it's the state of justice in many of our real-world societies.

The opposing concern is that the CoC has been used as a tool to defend the status quo or enforce minority opinion as policy. Or as Tobias puts it:

[...] we're now in a situation where large parts of the community do not trust our CoC structure because they feel it can be weaponized as part of internal power struggles.

Code of Conduct reports must be confidential and the decisions of the committee must be unimpeachable; under no circumstance can they become a matter of public opinion.

Unsurprisingly, there are very few situations that justify revealing any participant of a Code of Conduct report. Doing so has resulted in reputational damage such that an uncensored Google search of the name "Sonny Piers" returns pages of tabloid smear and speculation of criminality. Yet in the many months since, there has been no indication that this served the interests of community safety.

Although I acknowledge the community ban has since been relaxed to one year, I would like if we could each appreciate that to be stripped of membership, barred from ever holding a position in the Foundation and permanently banned from all community spaces is to be told, "You are irredeemable". Again, in the time of Sonny's absence, there have been no signs that the safety of the community ever warranted a permanent ban.

The good faith assumption seems to be that these actions were taken to send a message: the Code of Conduct will be enforced, regardless of a person's stature in the community. Unfortunately, if that was the intention, a number in the community have already expressed confusion that this situation received treatment so different from their own.

# Trust and Accountability

I spent a fair amount of time recently deciding whether I would renew my Foundation membership or not. Those in the Foundation working to rectify the breakdown of communication and policy are the reason I decided to stay. However, there are also those in the Foundation who have made me feel an unwelcome bystander to the very public condemnation of a colleague, only be told not to cause a fuss.

I strongly believe the CoCC operated on an unfounded assumption of bad faith: that Sonny Piers is a toxic influence to be immediately and permanently removed from the community. Since July, none of the corroborating signs have surfaced; few have had more contact with Sonny than a short email response, there has been no public appeal to gather signatures, no coup d'état in the Foundation and, with two months left on the community ban, fears of him being exempt from the rules seem moot.

A number of the recent policy improvements were prompted by the findings of the external review commissioned by the Foundation, but I'd like to clarify this was an assessment of whether the Code of Conduct Committee acted within its scope and authority; not a judicial review. The severity of corrective action has not been justified, nor did any review findings or policy changes apply retroactively.

While the Foundation has and will continue to improve, it seems unlikely we will see accountability for the mishandling of a situation that has caused damage to an individual, to the community and trusting relationships. For trust to be restored, we must be assured that Code of Conduct Committee is free from conflicts of interest and is only applied in the interests of community safety.

# Final Thoughts

I don't know what to do about this. I know there are those in the Foundation working very hard to improve the situation and those on the Board aware that they can just ignore criticism until their seat is up for re-election.

The GNOME Foundation is becoming a more important part of the GNOME project every year, but it is still extremely opaque to most of us. If there is a way to educate oneself as a voter I do not know it, and we must accept that has become a serious problem.

We can not have confidence in leaders elected on vague familiarity and then expect accountability from elections separated by two years. And the GNOME Foundation can not build trust in governance by appealing to its own authority.

03 May 2025 6:27pm GMT

This blog post talked about the "self written C++ standard library" I wrote for the fun of it (code here).

The post got linked by Hackernews and Reddit. As is usual the majority of comments did not talk about the actual content but instead were focused on two tangential things. The first one being "this is not a full implementation of the C++ standard library as specified by the ISO standard, therefore the author is an idiot". I am, in actual fact, an idiot, but not due to project scope but because I assumed people on the Internet to have elementary reading comprehension skills. To make things clear: no, this is not an implementation of the ISO standard library. At no point was such a thing claimed. There is little point in writing one of those, there are several high quality implementations available. "Standard library" in this context means "a collection of low level functions and types that would be needed by most applications".

The second discussion was around the fact that calling the C++ standard library "STL" was both wrong and proof that the person saying that does not understand the C++ language. This was followed by several "I am a C++ standard library implementer and everyone I know calls it the STL". Things deteriorated from there.

The complexity question

Existing container implementations are complex by necessity. They need to handle things like types that can not be noexcept moved or copied. The amount of rollback code needed explodes very quickly and needs to be processed every time the header is included (because of templates). A reasonable point against writing your own containers is that eventually you need to support all the same complexity as existing ones because people will insert "bad" types into your container and complain when things fail. Thus you need to have all the same nasty, complex and brittle code as an STL implementation, only lacking decades of hardening to shake out all the bugs.

That is true, but the beauty of having zero existing users is that you can do something like this:

This is basically a concept that requires the type given to be noexcept-movable (and some other things that could arguably be removed). Now, instead of allowing any type under the sun, all containers require all types they get instantiated with to be WellBehaved. This means that the library does not have to care at all about types behaving badly because trying to use those results in a compiler error. A massive amount of complexity is thus eliminated in a single stroke.

There are of course cases when you need to deal with types that are not well behaved. If you can tolerate a memory allocation per object, the simple solution is to use unique_ptr. OTOH if you have types that can't be reliably moved and which are so performance critical that you can't afford memory allocations, then you are probably going to write your own container code anyway. If you are in the position that you have badly behaved types that you can't update, can't tolerate an allocation and can't write your own containers, then that is your problem.

Iterating things the native way

One of the most common things I do with strings in Python is to split them on whitespace. In Python this is simple as there is only one string type, but in native code things are more complicated. What should the return type of mystring.split() be?

• vector<string>
• vector<string_view>
• A coroutine handle
• The method should be a full template so you can customize it to output any custom string type (as every C++ code base has at least three of them)
• Something ranges something something

There is probably not a single correct answer. All of the options have different tradeoffs. Thus I implemented this in two ways. The first returns a vector<string> as you would get in Python. The second one was a fully general, lazy and allocation-free method that uses the most unloved of language features: the void pointer.

So given that you have a callback function like this:

the split function becomes:

This is as fully general as you can get without needing to muck about with templates, coroutines or monads (I don't actually know what monads are, I'm just counting on the fact that mentioning them makes you look cool). The cost is that the end user needs to write a small adapter lambda to use it.

Iterating things the Python way

The Python iteration protocol is surprisingly simple. The object being iterated needs to provide a .next() method that either returns the next value or throws a StopIteration exception. Obviously exceptions can't be used in native code because they are too slow, but the same effect can be achieved by returning an optional<T> instead. Here's a unit test for an implementation of Python's range function.

Sadly there is not a simple way to integrate this to native loop constructs without macros and even then it is a bit ugly.

Current status

The repo has basic functionality for strings (regular and enforced UTF-8), regexes and basic containers.

Building the entire project has 8 individual compilation and linking steps and takes 0.8 seconds when using a single core on this laptop computer. Thus compiling a single source file with optimizations enabled takes ~ 0.1 seconds. Which is nice.

The only cheat is that pystd uses ctre for regexes and it is precompiled.

03 May 2025 12:40am GMT

Welcome! In classic new-blog tradition, I felt it was a good idea to explain the title given to this little corner of blogs.gnome.org - and provide fair warning as to what sort of thoughts I'll post here.

GNOME is the Computer

I've spent a lot of time lately answering the question "what is GNOME?" This question usually comes from my friends outside the tech industry. They work on film sets and fishing boats. They work in law firms, book stores, and hospitals. I don't usually have a whiteboard handy to explain what GNOME is, so I've found myself approaching the question like this:

Me: Have you heard of "Linux"?

Them: Yes.

Me: Okay, so. When you open your laptop and the thing you see is Windows? And when you unlock your phone and the thing you see is iOS? When you use a Linux computer, the thing you see is GNOME.

I'm committing multiple sins with this oversimplification but if any of my friends are willing to let me elaborate, I do. That rarely happens. To these folks, and to me, GNOME is the computer. It's the human part. The UI. The UX. The part you touch.

An Environment for Everyone

For those few friends who do permit me to elaborate, I'll spend a moment explaining free desktops. But if they're willing to put up with me, I'll turn the conversation back to GNOME.

After spending over two decades in the software industry, I've developed a deep appreciation for simple, opinionated, well-designed software. After a bicycle crash and three botched surgeries in 2014, I've also developed a deep appreciation for accessible software.

The word "accessibility" contains a lot of nuance. Our industry tends to associate that word with an icon of a little human, arms outstretched. Of course it's important for software to reach folks like me, who need to use computers in specific ways. But "accessibility" goes much farther than that.

The root of accessibility is access:

• Does the computer speak your language?
• Does the computer understand your culture?
• Can you afford it?
• Can you share it?
• Can you fix it yourself?
• Is it really yours?

Unlike most desktop software these days, GNOME can answer "yes" to all these questions.

GNOME is Infrastructure

Not only does accessible computing for everyone already exist, it is everywhere. I've seen GNOME in schools, wood shops, trading firms, government offices, universities, and every software company in my 20-year career.

Infrastructure - whether libraries, parks, roads, or sewers - is a drab topic compared to "computing for everyone". But it is no less important. Really, it is the other side of that coin and I'll have a lot more to say on this topic.

This blog will live at the intersection of these three topics: GNOME's identity, mission, and reach.

03 May 2025 12:00am GMT

April was light.

exempi

Released Exempi 2.6.6 to fix security issues from upstream.

libopenraw

Some minor fixes in the thumbnail extraction, with JXL support and locate larger Panasonic previews. Extract the exposure bias for Fuijfilm files. Added the latest Canon cameras (still the support of CR3 is work in progress).

Released alpha.10 on May 1st.

03 May 2025 12:00am GMT

Update on what happened across the GNOME project in the week from April 25 to May 02.

GNOME Core Apps and Libraries

Calendar

A simple calendar application.

Hari Rana | TheEvilSkeleton reports

As part of our volunteer-driven accessibility initiative in GNOME Calendar, and for the first time in the 10+ years of Calendar's existence, we finally completed and merged the first step needed to have a working calendar app for people who rely on keyboard navigation. This merge request in particular makes the event widgets focusable with navigation keys (arrow left/up/right/down) and activatable with space/enter.

Most of GNOME Calendar's layout and widgets consist of custom widgets and complex calculations, both independently and according to other factors (window size, height and width of each cell, number of events, positioning, etc.), so these widgets need to be minimal to have as little overhead as possible. This means that these widgets also need to have the necessary accessibility features reimplemented or even rethought, including and starting with the event widgets.

Third Party Projects

francescocaracciolo reports

Newelle 0.9.5 Released: Internet Access, Improved Document Reading

🔎 Implemented Web Search with SearXNG, DuckDuckGo, and Tavily 🌐 Website Reading: ask questions about websites (Write #url to embed it) 🔢 Improved inline LaTeX support 🗣 New empty chat placeholder 📎 Improved Document reading: semantic search will only be done if the document is too long 💭 New thinking widget 🧠 Add vision support for llama4 on Groq and possibility to choose provider on OpenRouter 🌍 New translations (Traditional Chinese, Bengali, Hindi) 🐞 Various bug fixes

Source Code Install it from Flathub

Elias Projahn announces

I have published the initial release of a classical music player and organizer designed for GNOME, which will eventually become a full-fledged tool for managing your personal library of classical music. The application is called Musicus and also comes with a small pre-made music library containing recordings that are in the public domain (based on EU legislation). This makes it very easy to try out the app, which is available as a Flatpak bundle. Please note that the application is not yet stable and mature. This is why I am looking for feedback on the design, functionality and, if you are interested in contributing, you!

Hari Rana | TheEvilSkeleton reports

Since Upscaler has just reached 150,000 installs on Flathub, I'm releasing Upscaler 1.5.0! Upscaler is an app that allows you to upscale images locally, securely, and completely offline.

Thanks to Zoey Ahmed's wonderful contribution, this release introduces the long overdue functionality to load multiple images at once and add them to the queue. This avoids having to load and add each image to the queue, which will significantly speed up the process of adding images to the queue.

The entire async and threading model was ported to the asyncio and threading modules, thanks to the long awaited (pun very much intended) asyncio integration in PyGObject that was made available recently.

Loading images has become much faster and smoother, while using less memory as a direct result of the asyncio and threading port.

This release also makes saving the resulting images completely optional. Additionally, there is now a copy button to copy images without saving them. As such, the process to upscale images has gotten more straightforward than ever - just load the image, set the desired scaling factor and the image type.

The progress rows have gotten a redesign to make them more reminiscent to typical rows with progress bars.

You can get Upscaler 1.5.0 on Flathub: https://flathub.org/apps/io.gitlab.theevilskeleton.Upscaler

Turtle

Manage git repositories in Nautilus.

Philipp announces

Turtle goes async again

Turtle 0.13 was released with proper Nautilus async plugin support!

Turtle switched back to the async update_file_info_full method recently and with this version many improvements have been made to reduce turtle service dbus calls to speed up emblem calculations. There is now also a setting to restrict emblems and the context menu to home folders, to even further reduce unnecessary service calls.

Making async possible again

Turtle used a workaround for a while, because there was a crash in Nautilus when update_file_info_full is used. This issue was fixed with this MR which is available in Nautlius 48+ and has also been backported to Nautilus 47.2 and 46.4.

The flatpak version still uses the sync workaround, because there is no way to guarantee the package is installed on a distro with a Nautilus version including the fix.

Packaging stuff

There was also some progress with debian and fedora packages of Turtle.

If you want to test the package now, there is PPA for Ubuntu 24.04 with the Nautilus fix backported.

Fractal

Matrix messaging app for GNOME written in Rust.

Kévin Commaille reports

A new version of Fractal numbered Eleven? Stranger things have happened… Features come running up that hill:

• Support for login using the OAuth 2.0 API (as used by matrix.org, which recently made the switch to Matrix Authentication Service)
• Overhaul of the page that lists user sessions, with details moved to subpages, for a less cluttered feel, and allowing to rename sessions!
• Rearranged account settings, with a new Safety tab that includes a setting to toggle media preview visibility
• BlurHashes for images and videos, that are used as placeholders while the media is loading or if the preview is disabled
• Contiguous state events are grouped behind a single item

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

We want to address special thanks to the translators who worked on this version. We know this is a huge undertaking and have a deep appreciation for what you've done. If you want to help with this effort, head over to Damned Lies.

This version should be available shortly on Flathub.

If you want to join the gang, you can start by fixing one of our newcomers issues. We are always looking for new members!

Blueprint

A markup language for app developers to create GTK user interfaces.

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

Blueprint is now part of the GNOME Nightly SDK and is expected to be part of the GNOME 49 SDK. This means, apps relying on blueprint won't have to install it manually anymore.

Blueprint is an alternative to defining GTK/Libadwaita user interface via .ui XML-files (GTK Builder files). The goal of blueprint is to provide UI definitions that require less boilerplate than XML and are easier to learn. Blueprint also provides a language server for IDE integration.

Many of our GNOME Circle apps are already built with blueprint, as well as some Core and Incubator apps.

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!

02 May 2025 12:00am GMT

Some links for technical articles on various topics I read.

The Defer Technical Specification: It Is Time - Explains the proposal for the next C language standard for defer.

A guide to implement ActivityPub in a static site (or any website) - A guide to implement ActivityPub in a static website.

20 years of git - An history of git and its early days.

Celebrating Git's 20th anniversary with creator Linus Torvalds - An interview with Linus Torvalds on the 20 years of git.

I use Zip Bombs to Protect my Server - A technique of serving compressed zeros that a lot of bots don't handle properly.

6 usability improvements in GCC 15 - New in a GCC 15 near you, better error messages.

02 May 2025 12:00am GMT

We have replaced Buildbot with a custom service, and we hope you haven't noticed.

Vorarbeiter is a German word for "foreman" and a living proof of my school-related trauma. The new service is a middleman between GitHub and GitHub Actions. It has been happily humming since April 21st, and largely does what Buildbot did: builds apps, with a sprinkle of publishing logic.

While what happens under the hood is solid, there is no UI yet. Flathub bot will still inform developers about build status for their pull requests, but there is little visibility of what happens post-merge.

Additionally, Vorarbeiter no longer allows to manually publish, cancel or delete builds. The publishing happens every hour regardless of the age of the build. The previous 3-hour-long delay was too conservative, and barely anyone was giving a final test for a post-merge builds. Similarly, cancelling builds doesn't seem as necessary as before. GitHub Actions runners are ephemeral and new commits on the same branch or pull request will automatically cancel the previous in-progress build.

Last but not least, because of limitations of the free GitHub Actions runners, some apps are designated as large builds. Large builds take place on machines provisioned in AWS, boasting faster CPUs and larger disks to accommodate heavier requirements.

While large builds do not incur costs per se thanks to the generous AWS credits for open source projects program, we still want to be mindful of how much credits we are spending, which is why we don't run large runners all the time. This is possible thanks to RunsOn, which handles all the magic for us. It receives pipeline events from GitHub and provisions new machines automatically within seconds, and tears them down the moment the build is finished. This is completely invisible to developers, but is both faster and more cost-effective, even if we were to pay the bill ourselves.

There is still more work to be done. I want to improve observability of the new service to make sure we can have automatic alerts when we have an abnormal build error rate or unprocessed publishing queue. In fact, we already notify maintainers and Flathub admins when a build triggered on the master branch failed, but there is potential to be more proactive here.

The unsolved challenge so far is caching. Every new pipeline re-downloads Flatpak runtimes, SDKs, and source code needed to build the app. Ideally, we should cache at least the runtimes, but with runners being ephemeral, we should also attempt to implement a distributed solution for ccache to reduce build times.

Given the challenging circumstances, this is more than good enough, though! If you encounter any issues with the new workflow, don't hesitate to open an issue in the project's GitHub repository.

02 May 2025 12:00am GMT

WebKitGTK has a bunch of different confusing API versions. Here are the three API versions that are currently supported by upstream:

• webkitgtk-6.0: This is WebKitGTK for GTK 4 (and libsoup 3), introduced in WebKitGTK 2.40. This is what's built by default if you build WebKit with -DPORT=GTK.
• webkit2gtk-4.1: This is WebKitGTK for GTK 3 and libsoup 3, introduced in WebKitGTK 2.32. Get this by building with -DPORT=GTK -DUSE_GTK3=ON.
• webkit2gtk-4.0: This is WebKitGTK for GTK 3 and libsoup 2, introduced in WebKitGTK 2.6. Get this by building with -DPORT=GTK -DUSE_GTK3=ON -DUSE_SOUP2=ON.

webkitgtk-6.0 contains a bunch of API changes, and all deprecated APIs were removed. If you're upgrading to webkitgtk-6.0, then you're also upgrading your application from GTK 3 to GTK 4, and have to adapt to much bigger GTK API changes anyway, so this seemed like a good opportunity to break compatibility and fix old mistakes for the first time in a very long time.

webkit2gtk-4.1 is exactly the same as webkit2gtk-4.0, except for the libsoup API version that it links against.

webkit2gtk-4.0 is - remarkably - mostly API stable since it was released in September 2014. Some particular C APIs have been deprecated and don't work properly anymore, but no stable C APIs have been removed during this time, and library ABI is maintained. (Caveat: WebKitGTK used to have unstable DOM APIs, some of which were removed before the DOM API was eventually stabilized. Nowadays, the DOM APIs are all stable but deprecated in webkit2gtk-4.1 and webkit2gtk-4.0, and removed in webkitgtk-6.0.)

If you are interested in history, here are the older API versions that do not matter anymore:

• webkit2gtk-5.0: This was an unstable API version used during development of the GTK 4 API, intended for WebKit developers rather than application developers. It was obsoleted by webkitgtk-6.0.
• webkit2gtk-3.0: original API version of WebKitGTK for GTK 3 and libsoup 2, obsoleted by webkit2gtk-4.0. This was the original "WebKit 2" API version, which was only used by a few applications before it was removed one decade ago (history).
• webkitgtk-3.0: note the missing "2", this is "WebKit 1" (predating the modern multiprocess architecture) for GTK 3. This API version was widely-used on Linux, and its removal one decade ago precipitated a security crisis which I called The Great API Break. (This crisis was worth it. Modern WebKit's multiprocess architecture is far more secure than the old single-process architecture.)
• webkitgtk-1.0: the original WebKitGTK API version, this is "WebKit 1" for GTK 2. This API version was also widely-used on Linux before it was removed in The Great API Break.

Fedora and RHEL users, are you confused by all the different confusing downstream package names? Here is your map:

• webkitgtk6.0, webkit2gtk4.1, and webkit2gtk4.0: This is the current binary package naming in Fedora, corresponding precisely to the WebKitGTK API version to reduce confusion.
• webkit2gtk3: old name for webkit2gtk4.0, still used in RHEL 9 and RHEL 8
• webkitgtk4: even older name for webkit2gtk4.0, still used in RHEL 7
• webkitgtk3: this is the webkitgtk-3.0 API version, still used in RHEL 7
• webkitgtk: this is webkitgtk-1.0, used in RHEL 6

Notably, webkit2gtk4.0, webkit2gtk3, and webkitgtk4 are all the same thing.

28 Apr 2025 5:00am GMT

Introduction:

GNOME GitLab now uses macOS runners from MacStadium for managing our macOS CI pipeline. This offers significant improvements in supporting the GNOME platform on macOS. In this blog, we'll cover the event timeline of macOS CI in GNOME GitLab and the technical details of the new infrastructure setup from MacStadium.

Background:

Around mid 2023, the GNOME Infrastructure Team decided to retire the existing macOS CI runners for a handful of reasons as explained in this post by Emmanuele Bassi. They were x86_64 runners which were quite outdated technically, as they were replaced by better and faster Apple Silicon M series ARM SoCs (specifically Apple M1) from Nov 2020.

There was no macOS CI in GNOME GitLab since then. GNOME core projects like GTK, GLib and few apps still provided macOS support on a best effort basis: meaning development and testing would be done on user machines. Though this is far from perfect, this provided some basic macOS support for GNOME projects.

Infrastructure help from René:

René de Hesselle is a member of Inkscape's Project Leadership Committee and an open source developer who specializes in building, packaging and porting applications to the macOS platform. Looking into the macOS CI issues GNOME projects were facing, René offered to help with the macOS effort in GNOME, which was greatly appreciated by GNOME developers.

René has been assisting core libraries like GLib, GTK and GNOME apps to build in macOS. To address the macOS CI limitation, René went a step further and provided a self hosted GitLab macOS CI runner. With assistance from the GNOME Infrastructure Team, the self hosted runner was made available to projects across GNOME. This proved to be really useful, as it increased the pace of development in macOS.

Scalability and Sustainability Issues:

Over time, as more projects switched to using the self hosted macOS CI runner, it was becoming evident that this solution would not be effective for the scale of GNOME and not sustainable in the long term. René opened this topic for discussion in this post.

It was quite evident that we needed an enterprise solution to offer scalable and sustainable macOS CI service. This is when MacStadium's FOSS program was highlighted as a possible solution in GNOME Discourse.

MacStadium, FOSS and GNOME:

MacStadium is well known in the open source world for sponsoring developers of open source projects for the Apple platform, including macOS, iOS, tvOS, and watchOS.

The GNOME Team got in touch with MacStadium for sponsoring macOS CI runners under their FOSS program. Though the MacStadium FOSS program was not available as it was already at capacity, MacStadium was excited in partnering with GNOME. Special thanks to Lauren Cabana (Director, Marketing) from MacStadium for actively pursuing this effort and making this collaboration possible.

MacStadium Orka Cluster solution:

As part of this collaboration, MacStadium has offered the following infrastructure setup based on our requirements:

• Orka (Orchestration with Kubernetes on Apple) Cluster.
• Dedicated network with firewall and VPN.
• 1 TB NAS storage.
• 2 x Mac mini (M1, 8-core CPU, 10-core GPU, 16GB RAM, 1TB SSD).

This is a significant bump in hardware specs compared to the current solution, allowing us to run more builds simultaneously. But the biggest benefit is having access to a turnkey solution that provides ephemeral machines: build isolation is no longer a concern and restrictions on customizability can be lifted, making it possible to open macOS CI instance-wide on GNOME GitLab with minimal administrative oversight. This setup is located in MacStadium's Dublin data center.

Thanks to MacStadium for sponsoring this infrastructure upgrade!

Thanks and Mentions:

• Richard Littauer - for interfacing with MacStadium via calls / emails and active participation.
• René de Hesselle - for actively taking part in all technical discussions.
• Philip Withnall - for coordinating efforts within GNOME.
• Bartłomiej Piotrowski - for setting up GNOME / MacStadium accounts.

27 Apr 2025 9:00am GMT

I know that I will never convince everyone to use Builder for development. Even I have a hard time getting myself out of the terminal at times.

Foundry comes in two forms, an executable and a library. The executable is just a bunch of commands and libfoundry is meant for building your own IDE (like Builder) or specialized tooling.

# initialize .foundry directory if never done before
cd my-project/
foundry init

If you go into most GNOME applications, they likely have a Flatpak manifest. Builder uses this to auto-discover a lot about a project. Foundry is no different.

# Build the project, just like Builder would do
foundry build

You can run this from any directory in your project as it will scan upwards to locate the .foundry/ directory that contains project state. It will also do incremental building just like Builder does.

# Run the project, just like Builder would do
foundry run

# Run a specific command in place of the default program.
# Useful to test something with "runtime" instead of
# build environment.
foundry run -- gtk4-demo

Running the project will setup the necessary incremental flatpak pipelines and auxiliary tooling like an a11y bus, font integration, and what not. Your application will be run in the Flatpak build container based on the finish-args.

This does require building the application to ensure the runtime environment is setup correctly.

# Pull updated project dependencies.
foundry dependencies update

Updating your deps is pretty painless. This is not done automatically unless the dependency is missing so that we don't have to constantly hammer remote servers on every build request.

# Run a shell in the build pipeline, launches in builddir
foundry devenv

# Run a specific command in build pipeline
foundry devenv -- ps aux

You can get a terminal shell in the build pipeline (much like ctrl+alt+shift+t in Builder.

# Lots of commands to inspect the build pipeline
foundry pipeline info

# Alias to foundry build
foundry pipeline build

# Invalidate all pipeline stages
foundry pipeline invalidate

# Purge (remove build files/artifacts/etc) to force
# a clean build
foundry pipeline purge

# clean, configure, export, rebuild, which, install
# all provide additional pipeline operations

You can interact with the active build pipeline using the above commands.

Sometimes you might want to know what compiler flags will get used with tooling on a specific file. That is made available via the pipeline as well.

foundry pipeline flags path/to/file.c

Maybe you need a language server for integrating with another editor. That is pretty easy to do for the supported languages by using the lsp command.

$ foundry lsp list 
Name                  Languages
zls                   'zig'                                   
vhdl-language-server  'vhdl'                                  
vala-language-server  'vala' 'genie'                          
ts-language-server    'js' 'jsx' 'typescript' 'typescript-jsx'
sourcekit-lsp         'swift'                                 
serve-d               'd'                                     
rust-analyzer         'rust'                                  
ruff                  'python3' 'python'                      
pylsp                 'python3' 'python'                      
mesonlsp              'meson'                                 
lua-language-server   'lua'                                   
jedi-language-server  'python'                                
jdtls                 'java'                                  
intelephense          'php'                                   
gopls                 'go'                                    
glsl-language-server  'glsl'                                  
elixir-ls             'elixir'                                
clangd                'c' 'cpp' 'chdr' 'cpphdr' 'objc'        
blueprint             'blueprint'                             
bash-language-server  'sh'                                    

# use stdin/stdout to communicate with an LSP for python3
$ foundry lsp run python3

If you have multiple project configurations, you can look through them and select the active one. Just switch configs and run, Foundry will do the rest.

foundry config list
...
foundry config switch flatpak:app.devsuite.Manuals.Devel.json
foundry run

Want to get a .flatpak you can copy to another system to test?

foundry export
...
Artifacts:
  file:///.../apps.devsuite.Manuals.Devel.flatpak

You can switch devices in case you have deviced running somewhere like a phone or tablet. Then running should deploy to that system and run it there.

foundry device list 
...
foundry device switch some_device
foundry run

You can get the URI to documentation which could allow you to integrate with other editors. Like many commands, you can use --format=json to get the output in an easy-to-parse format for editor plugins.

# list available doc bundles to install
foundry doc bundle list
...

# install docs for GNOME 48
foundry doc bundle install flatpak/org.gnome.Sdk.Docs/48/user

# Find GtkWidget documentation
foundry doc query --format=json GtkWidget

Many settings can be tweaked using foundry settings set .... Just tab-complete around to explore.

Anyway, hopefully that serves as a quick intro into some of the things you can do with Foundry already as it progresses towards being a fully-fledged replacement for Builder's internals.

26 Apr 2025 8:04pm GMT