I got funding from my employer to attend the GNOME conference, and one of the requirements is that I write a "conference report" mail with a summary of what I got out of it.

I'm going to share that email here, with a bit of extra context. If you're reading my blog - you're either quite involved in GNOME, or maybe you know me personally and don't have much of a clue why I go on about gnomes all the time. This email was written for an audience which is largely software engineers, many with an interest in open source and many using GNOME to do their work, but relatively few who are actively developing desktop software or participating as volunteers in big open source projects.

I'm just back from the GNOME project's annual meetup. This year it was in A Coruña (near my adopted home town Santiago), where the University has a functioning Linux user group (GPUL) and 5 members did an amazing job as the local organizing team.

The conference is open to GNOME users and anyone interested in open computer interfaces, but it tends towards *intra-project* communication since its the one time that everyone in GNOME gets into a single place.

Given that, the talk I'm going to recommend is part 2 of the GNOME Foundation AGM:
https://www.youtube.com/live/Q4O7dhreLDU?si=eGxbIIq3TkVtuty1&t=6739

If you've been in the software world more than 5 minutes you'll know that high quality code doesn't go on trees, and if you've been involved in any kind of community-led initiative you'll know that volunteers do not just appear out of nowhere either. GNOME provides a nice interface to use your computer, but also an independent legal entity that is funded and managed by its members, with membership open to anyone who participates actively in the project, and a Board of Directors elected democratically from the membership.

This part of the AGM was mainly presented by Allan Day, he is primarily a UI designer working at Red Hat but has also dedicated a lot of energy to the non-profit Foundation during a series of quite turbulent years, and for the last year was acting as President of the foundation.

Some highlights from the presentation if you don't want to watch the whole thing:

• There are now nearly 1,000 recurring monthly donations from individuals via the "Friends of GNOME" program.
• This allows running a year-long "Fellowship" initiative which will fund the work of two long-time volunteer contributors.
• The Foundation has successfully cut expenses in the last 2 years, including reducing the number of paid staff, and balanced its budget in the short term.
• Many of the people currently running the Foundation are overworked and dealing with burnout.
• There needs to be an active effort to maintain and increase the number of monthly donors for the project to survive.

This kind of management work might seem dry, but its really an essential part of any project with more than a handful of members, and I think Allan's intuitions as a designer meant that the presentation was a lot more informative and accessible to outsiders than your average AGM.

Of course, GUADEC is also a good place to find a subset of the Freedesktop SDK community. I did a lightning talk about my mission to allow swapping out the shell & utilities in Freedesktop SDK:
<https://www.youtube.com/live/Q4O7dhreLDU?si=DFHAFHJxnG8j7SLh&t=26403>. And we landed this branch in time for FDSDK 26.08, which is good news for those of us building operating systems with FDSDK and BuildStream.

There is plenty more to watch in the videos if you're interested in open source desktop and mobile software… including some talks by Abderrahim and some workshops run by Javier, but I'll leave them to highlight what happened in those

Thanks as always to Codethink for sponsoring us to attend.

22 Jul 2026 11:58am GMT

While you (yes, you! no, not you, the one behind you) have been sweltering in the heatwaves of the northern hemispheres (Assisted-by: AI), I've been busy adding graphics tablet support to libei. This is scheduled for the soon to be released libei 1.7.0.

The initial work was done by Jason Gerecke and Josh Dickens from Wacom, I've been extending, polishing and testing it for the last few weeks.

Also, upfront: this only covers the stylus part of a tablet, we do not yet have an implementation for the "pad" part (the buttons, dials, rings, strips).

libei is, of course, the library for Emulated Input, a good-enough transport layer for sending logical input events between processes. We're already using libei as part of the XDG Portal Remote Desktop and Input Capture portals where we've been busy hurtling key and pointer events between the participating parties (and soon gesture events and text).

In the next release of libei, we will now also have "ei stylus" capabilities, i.e. the ability to send tablet stylus events. Getting pointer, keyboard and touch events supported was a long undertaking, everything was new and shiny and needed to be added everywhere in the stack. Now that all this is in place, scuffed and scratched, adding tablet events will be quite simple.

The ei stylus interface

Here's a short outline of how libei handles tablet events because it is, of course, different to how libinput handles them. Logical events are much nicer after all than physical hardware events.

First: we have a new interface: "ei_stylus". An EIS implementation (e.g. your compositor) may provide you, the libei client, with a device that supports this interface and one or more associated regions (typically representing the available screen areas). Typically this will be a separate device to the pointer devices or the keyboard devices but it's not a requirement. The ei_stylus interface comes with a bunch of capabilities you'd expect from a stylus (tilt, pressure, distance, ...) that you can selectively enable to emulate the stylus you want to. So basically, EIS will say "here's a stylus device, I support pressure, tilt, rotation, ..." and then the libei client says "This stylus should have pressure and tilt but nothing else". And then you do the normal thing: send proximity events, send tip down/up events, send data for the various capabilities you've enabled.

Happily for the EIS implementation, libei forces the client to take the guesswork out of everything: if you select the pressure capability, you must send a pressure value when coming into proximity. Where libei is used to forward data from a physical stylus (e.g. via some remoting protocol) it is up to the client to deal with firmware bugs that e.g. won't send data until a few frames in.

Note that there is no "tablet" anywhere. The tablet is represented by the region that the device may interact with. So in some ways every tablet is an on-screen tablet (which makes sense since we have logical events).

Multiple styli

The only quirky thing is how to request multiple styli[1]: libei 1.5.0 has added a "request device" request that allows a client to say "hey, EIS, I want a new device with capabilities pointer, keyboard, ...". And, if you've been a nice client, minding your own business, the EIS implementation may just create such a device for you.

So for the case of multiple styli: if the default stylus (if any) isn't good enough, you can now tell EIS that you want a(nother) device with stylus capability, configure the stylus capabilities once the device shows up and voila, you now have a normal pen, an art pen and maybe even an airbrush represented as logical device in libei. And since they're all separate devices in the protocol, they can be individually tracked and used, much like libinput tracks individual styli.

[1] For the "lots" of users that actually use multiple styli...

22 Jul 2026 4:46am GMT

/me gestures vaguely at everything

Oh, hey, this works now? Great!

libei 1.7.0 (to be released soon) comes with a new interface: "ei_gestures" which, creatively, will allow for gestures to be sent between a libei client and an EIS implementation (typically: a Wayland compositor).

I'm not going to go too deeply into how pinch, swipe and hold gestures work, suffice to say we've had those in libinput (for touchpads) for years now so compositors and toolkits should already support those. And since libei and libinput have vaguely equivalent API layers integrating gestures for libei devices in compositors should be fairly straightforward.

The plumbing layers in the portals exist already too, so adding gestures to libei means that - once the compositors support it - we can have gestures support in remote desktop and input capture implementations without needing to update anything else. Hooray! Join in with me. Hooray! Louder! HOORAY!

For testing I had a (vibe-coded and thus immediately abandoned once testing was complete) gesturemouse utility which translates input events from a mouse into gesture events (depending which button is down). But don't let my lack of be a limit to your imagination, I'm sure you can come up with good use-cases for this.

22 Jul 2026 4:22am GMT

If you've been paying attention (and I know you have, because it'd be embarrassing for you if you didn't) you'd have noticed that libei 1.6 (May 2026) added support for keysym and text events.

libei sends logical events between a libei client and an EIS implementation (typically: a Wayland compositor) but the keyboard interface it had was designed like real keyboards: key codes together with an (XKB) key map. You press one key, the keymap decides what that key means on the compositor side and off we go. This is easy but not always useful.

As of 1.6.0 libei now also supports an "ei_text" interface. A compositor may choose to provide you[0] with a device that supports this interface and that gives you two really nice opportunities.

First, you can now send a key sym. Instead of sending the KEY_Q key code and hoping it actually translates to 'q' (and if there's e.g. a frenchman^Wfrenchperson lurking behind the keyboard it may mean 'a'), you can now send 'q' as actual keysym. Or 'Q' instead of sending shift+q and hoping for no french influence in the process. It becomes the EIS implementation's job to handle that keysym - if it's a shortcut it may handle it directly, otherwise it may pass it on via Wayland to an application[1]. This centralises the keysym to keycode handling in the EIS implementation which is a pain for compositor authors (though they likely have that code already for e.g. RDP support) but reduces the variety of differently-wrong implementations in clients and of course makes it so much simpler to write clients.

Second, a client can send UTF-8 text to the compositor. So instead of emulating shift, keycodes, etc. you can literally send "Hello World" and expect the EIS implementation to pass that one. Again, makes a bunch of utilities a lot simpler to write and I mostly leave it up to your imagination to figure out what to do with that.

Notably for both cases: libei is about logical events that have a specific meaning that do not need further interpretation. If a client sends 'Q' that means it is supposed to be an uppercase Q. Sending keysym Shift_L and Q makes little sense. And for the utf8 text events: how the text comes to be matters doesn't matter for libei so you may use an IM to make up the text to begin with and send it, once committed, to EIS. It's not for sending partial strings.

As mentioned in the previous post: the plumbing for this is already in place so both clients and compositors can add support for this new interface without having to bother the rest of the stack (e.g. portals). So, hooray I guess.

The text/keysym support is relatively recent so expect this to hit the next compositor version (or the one after that).

[0]: the EIS implementation decides which devices are available and arguing about this is even less useful than arguing with a world cup ref
[1]: after converting it to a key code with possible keymap changes... but hey, such is life

22 Jul 2026 4:16am GMT

Turns out it's been years since I've talked about eggs, so let's change this. libei is, of course, the library for Emulated Input[1].

This post is mostly a refresher because it's been so long and a short summary of some of the work we've done so far, in preparation for some more posts that come soon.

libei is a transport layer for logical input events, unlike libinput which is a hardware abstraction layer. In libinput's case the device's firmare/kernel pass events that are somewhere on the sanity spectrum, libinput tries to make sense of those and then we convert those to logical events to be consumed by the next layer (typically the Wayland compositor or Xorg). This is how e.g. "touch down at position x1/y1, touch up at position x1/y2" is converted into a button click event if touchpad tapping is enabled. Or maybe into nothing if we find it was an accidental palm touch.

libei works purely on the logical level - you as the libei client pass logical events to the EIS (Emulated Input Server) implementation (typically the compositor). No guesswork, you say button click, EIS gets a button click. libei supports a "sender" and "receiver" mode, depending on whether events are sent to the EIS implementation (input emulation) or receive from the EIS implementation (input capture). libei is designed for the Wayland stack but there are zero requirements for Wayland on either the client or the EIS implementation.

Core to libei's design is that the EIS implementation is in control of virtually everything, it decides which devices are available to the client, when those devices can send events, etc. Much like the compositor is in charge when it comes to physical devices - if a compositor decides a physical device doesn't exist, a Wayland client cannot get events from it.

Since the original proposal (again, [1]!) we've been busy bees and libei is now a part of the XDG Remote Desktop portal and the XDG Input Capture (both since version 1.17, mid 2023). In both cases the portal is for the negotiation and initial agreement of what should happen, libei is then used as the transport layer between the two processes [2].

More recently we also added session persistence support so you don't have to allow access on every connecton. Much of the work enabling this was done by Jonas Ådahl, it is now in the portals since version 1.21.0 and should be in the major compositors in the current or next versions.

Plumbing the Pipes

Getting all this into place was a huge amount of work across several pieces of the stack. This isn't exciting in the same way as laying plumbing pipes isn't particularly exciting but much like regular plumbing: once it's in place you can change your diet without severely impacting everyone again. Try get that analogy out of your head now. You're welcome.

In libei's case this means three things:

• if you have a client that uses the XDG portals to send/receive events they will now work with any compositor that implements the portal. No need for GNOME/KDE/... specific APIs.
• if you have a compositor that implements EIS you have all the infrastructure in place to talk to libei clients from somewhere else, if need be. The use-cases for this aren't fully scoped yet (assisitive technologies, virtual keyboards, touchpads, etc?) but the piping is there and ready to be (ab)used .
• since the actual events back and forth don't affect the layers in between, we can now add new events to libei without having to change everything else again.

Let's look at how this works in practice.

The XWayland XTEST use-case

An example for such a case where we can now abuse the piping is Xwayland support for XTEST. XTEST is the protocol that everyone uses to emulate input under X but in Wayland it's not hooked up to anything so those APIs simply won't work.

But what we can do in Xwayland is translate XTEST to libei events and facilitate the portal interaction. This means our stack looks roughly like this:

    +--------------------+             +------------------+
    | Wayland compositor |---wayland---| Wayland client B |
    +--------------------+\            +------------------+
    | libinput |   EIS   | \_wayland______
    +----------+---------+                \
        |          |           +-------+------------------+
 /dev/input/       +-----------| libei |     XWayland     |
                               +-------+------------------+
                                                |
                                                | XTEST
                                                |
                                         +-----------+
                                         |  X client |
                                         +-----------+

And if said X client uses XTEST to try to emulate devices, Xwayland will ask the Remote Desktop portal for permission and set up the session, then pass the XTEST events on as libei events and voila - your 20 year old X client can send pointer and keyboard events through an XDG Portal without knowing about it (and the user can prohibit this and even gets some information on who is sending events which is not possible with normal XTEST at all). This has now been supported since Xwayland 23.2.0. Compositors don't need extra support for this.

What's next

So we have a lot of the plumbing in place, or in another anology: we have a hammer, let's go looking for nails. And right now the nails we can see are sending text, gestures, and tablet support. And those will be the subject of the next few posts.

[1]: 6 years ago?! whoah...
[2]: in Remote Desktop's case replacing the DBus emulation APIs which were a Newton's Cradle of wakeups for at least 4 processes per event

22 Jul 2026 4:07am GMT

Due to the increase in AI-generated security vulnerability reports, it is time for some changes in how GNOME manages vulnerability reports.

These policy changes intentionally do not distinguish between reports that contain AI-generated content and those that do not. Following the same rules for all vulnerability reports is simpler than having two different ways of doing things. Reporters rarely disclose AI use, and it's nice to not have to guess whether the issue report is AI-generated or not; it's normally obvious, but not always. Also, vulnerability reports that are not discovered by AI are becoming increasingly rare. Non-AI reports are now moderately unusual, so it really doesn't make sense to optimize for them.

Reduced Disclosure Deadline

Traditionally, I have applied a 90 day disclosure deadline to all security issues reported to GNOME Security. 90 days is an industry standard timeline, but it doesn't work particularly well for GNOME. In practice, almost all GNOME maintainers handle vulnerability reports in one of two ways:

• The project maintainer fixes the issue quickly, typically within 1-3 weeks after it is reported.
• The project maintainer does not fix the issue at all. The issue report eventually reaches the 90-day disclosure deadline, at which point I unset confidentiality.

The 90-day deadline is intended to allow project contributors time to fix the issue before it becomes public, but in practice, maintainers do not actually make use of most of this time. I disclose the issue report and request a CVE when it is fixed or when the disclosure deadline is reached, whichever comes first. Once a CVE is assigned, contributors who are not regular project maintainers will sometimes attempt to fix it. Accordingly, keeping the issue reports confidential for 90 days only introduces a delay that is not useful.

Some other projects, notably the Linux kernel, have implemented an immediate full disclosure policy for issue reports that seem to be AI-generated, on the basis that a vulnerability that can be discovered by AI is presumably already known to attackers. But this policy seems pretty extreme, and is certainly unkind to maintainers who might feel pressured to urgently fix the issue. Immediate disclosure would not work well for GNOME.

Instead, I will switch to a 30 day disclosure deadline for issues reported on August 1, 2026 or later. This seems like a good compromise. The shorter deadline would probably work better for GNOME even if not for the increase in AI-generated issue reports.

Procedure for Projects that Prohibit AI-Generated Content

If a project prohibits issue reports that contain AI-generated content, I will no longer forward security issues reported to GNOME Security to the project's issue tracker, since the overwhelming majority of vulnerability reports contain AI-generated content and would violate the project's policy. Instead, I will immediately close the issue report in the GNOME Security issue tracker, then ping the project maintainers to let them know about the existence of the report. If you prefer to receive vulnerability reports in your project's issue tracker, then please change your project's AI policy to make an exception for vulnerability reports.

Unfortunately, GNOME maintainers don't have access to confidential issues in this issue tracker, and GitLab does not allow CCing individual developers on confidential issue reports. I had been planning to adopt immediate disclosure for these issues only, but perhaps we should instead expand the permissions to allow all GNOME developers to see the issue tracker. Opinions welcome.

Moving On

I have been managing GNOME security issue tracking since November 2020. (Thank you to Red Hat for supporting this work.) Security tracking is largely a secretarial duty: I keep track of issues when they are reported and when they are closed, disclose them when the deadline is reached, and request CVEs when appropriate. It is not a huge amount of work, but I am getting tired of it, so it's time for a change. I will discontinue tracking newly-reported security issues on November 1, 2026. During November, I will focus only on tracking issues reported prior to November 1. By December 1, all disclosure deadlines for that set of issues will have been reached, and I will be done.

Currently nobody else is tracking GNOME security issues. If you are an experienced GNOME community member and you are interested in taking over this work, let me know and I will help you get started. (Security tracking is not a good task for newcomers.)

This may also be an opportunity to improve our tracking infrastructure. I use a wiki page, but this is fairly primitive and requires considerable manual upkeep. It's easy to forget to update the page when an issue report is closed, for example. Ideally, we would replace the wiki with a proper web app that dynamically updates based on the actual state of the issue.

20 Jul 2026 1:20pm GMT

Jonathan Blandford asked me to do an icon set for Crosswords. What started as a request for a small group of symbolics, turned into a more flexible set of colourful sidebar icons.

Crosswords has been in the process of joining GNOME Circle for a while and hopefully this is another step in the right direction.

Metaphors

We narrowed down the main categories of puzzle sources to newspapers, collections, and custom. Together with unique recolourable overlays for each kind of puzzle, it creates a cozy, rich, yet scannable sidebar to easily pick the right puzzle for the moment.

Have fun puzzling!

19 Jul 2026 12:00am GMT

Introduction

The Linux desktop has an upstream maintenance problem due to many reasons for it, such as the lack of paid work. No one is entitled to a volunteer's free time apart from the volunteer themself. This is especially true to volunteers working on upstream projects, as they are at the mercy of downstream distributions, who have the final say.

As an upstream contributor, you have no choice but to meticulously plead for any reasonable request to be granted by difficult downstreams, treating them as if they are some kind of deity. Not doing so with the utmost respect can get you on their naughty list, which they can then use against you just because the license 'allows' it and they can get away with it; even shamelessly use the 'you chose the wrong license' card when they have nothing else to add.

We have seen several instances of downstreams misusing their power while simultaneously abusing upstreams' generosity and free time to do whatever they want. This was especially true with XScreenSaver and Debian in the past, which Debian has since changed its policies to communicate better with upstreams, and more recently Bottles, OBS Studio, and Fedora. This article is specific to an even more recent incident we at GNOME Calendar have had with Linux Mint.

Technical Definitions

There are a few technical definitions that should be understood before reading the rest of the article:

• Upstream: A group of individuals authoring software, for example GNOME Calendar.
• Downstream: A group of individuals building, curating, and redistributing these software to end users, for example Linux Mint.

The distribution model works until it impacts upstream

Distribution model refers to an established model that the Linux desktop has been practicing for decades, where an end user is expected to report issues to downstream, and, if necessary, downstream relays said issue to upstream.

The adage that users report issues to downstream holds true up until these users start reporting them to upstream without reporting to downstream beforehand. In reality, many distributions advertise themselves as user-friendly. Users of these distributions are unaware of the distribution model, so, in good faith, they report issues to upstream without ever knowing that they should be contacting downstream.

Often, downstream issues have already been resolved in previous releases; however, since these issues are being reported to upstream, upstream has to regularly triage and close these invalid issues. This creates an additional burden for them because they end up spending their limited volunteer time managing these issues when it should have been downstream's responsibility to ensure that the user is reporting to them first.

Contacting downstream is a burden in itself

Whenever the upstream project reaches out to the hostile downstream and asks for a change, the response is usually met with the downstream bluffing by pretending to look for a solution for a nonexistent request, such as adapting the issue tracker with the implication that upstream will have to write the template(s) themselves, and then regularly update when the message is misinterpreted, just so downstream can avoid doing any actual work. That is called moving the goalposts.

If upstream objects to these 'suggestions', this is usually done with a shift in tone, as these one-sided discussions occur in the span of weeks, if not months, if not years, which quickly drains upstream's remaining energy. When it shifts to a harsh(er) tone, the hostile downstream takes the easy way out by making remarks on that tone and acting like they are the only one being dignified; when they can, they end the discussion just because they do not like the tone and can use that tone to justify their (lack of) decision, without taking any appropriate action to remedy the underlying request.

As a result, they continue to mislead users into reporting issues to upstream, but this time intentionally and out of spite simply because free software licenses do not disallow abusing people's generosity and free time. However, you will see later that this has nothing to do with free software.

Linux Mint and GNOME Calendar

For years, we have been dealing with users reporting Linux Mint's broken packaging of GNOME Calendar to us, that were either never present or addressed releases ago.

To name a few examples:

• https://pouet.chapril.org/@parrot_33/116374864921983890^(Archive)
• https://vmst.io/@doctroid/116542487573304110 (dead link)
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/300
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1562
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1535
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1526
• https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1429
• https://matrix.to/#/!koZzDOwNHEzEoeuNok:matrix.org/$174759788212004HiyFg:gnome.org?via=gnome.org&via=matrix.org&via=fedora.im

There were a couple of discussions regarding this in the past, in chat and without my involvement, but none of them ended up being productive. Eventually, we got fed up by it and I opened ticket #1 on Linux Mint's "gnome-calendar" repository, asking them to remove all links pointing to upstream GNOME Calendar and rebranding the app:

Remove/replace links pointing to GNOME Calendar, and update branding

Being one of the core developers of GNOME Calendar, we do not support any of the versions provided and held back by Linux Mint. We would really appreciate if you could remove or replace every link, especially support links, targeting to GNOME Calendar, as well as rebranding the app icon.

Mind you, this is the first issue ever opened in the history of Linux Mint's package repository (8 years ago)! Based on the links above, I think it is safe to say that the app was broken throughout these years despite the lack of tickets.

This ticket had no response for six months, in other words half a year, all the while we were still getting bug reports about their broken package.

We eventually got fed up (again!) and pinged the packager. The packager replied and asked which modifications we did not like, conveniently ignoring our actual request.

So, I stated that we do not have the time to look through the code just to pinpoint specific issues, so I loosely said "everything"; then followed up by stating that the only solution to this is to rebrand or drop the package.¹ (Of course, it should not be our responsibility as an upstream to pinpoint issues to downstream's mispackaging.)

Then, the packager responded with "I reviewed the changes. None of them are problematic.", ignoring the essence of my comment once again, and followed with a whataboutism:

[…] [GNOME Calendar] 46 and 48 are used by millions of people right now in Ubuntu LTS and Debian Stable. Are you going to request Debian and Ubuntu stop shipping GNOME apps?"

In other words: "what about Ubuntu LTS and Debian Stable?", essentially roping Ubuntu and Debian into Linux Mint's problem. As a bonus, they also twisted my words and changing the subject from "GNOME Calendar" to "GNOME apps".

So, once again, I reminded that this is not what the issue is about, and Debian and Ubuntu LTS have nothing to do with this.

As a side note: no, never would we go after Debian or Ubuntu over this. If the distribution in question is doing its job properly by simply not bothering the people writing the software that they package, then why should we go after them? They are not the ones misleading users into opening in the wrong place, so there is no reason for us to be upset about. In this case, Linux Mint is leeching off of Debian, pushing their responsibility onto us, and roping Debian into their problems.

The packager then explained the following:

If we were to stop packaging GNOME Calendar, Mint users would end up with the exact same version 46 as now. You understand that? It wouldn't magically upgrade their version of GNOME Calendar to 50+.

Very clear signs of strawman to make points against a proposal/demand that was never made, by arguing against 'stop packaging GNOME Calendar' rather than the original 'rebrand GNOME Calendar'.¹

Then:

Mint 22.x is built on top of Ubuntu 24.04 LTS. Packages come from both repositories. If there's no gnome-calendar in Mint 22.x repositories, Mint 22.x users get it from the Ubuntu 24.04 repositories. The version in both repositories is 46. Removing gnome-calendar from our repositories would basically make our users switch to Ubuntu's version, which is 46 as well.

Same goes for LMDE and Debian Stable, same principle, same bug fix, with version 48.

The only way to make it so Mint doesn't have a frozen version of gnome-calendar would be to remove it from Debian. It would then disappear from future versions of Ubuntu and Mint which are based on it. If you got it removed from there we'd obviously oblige with your request not to re-add it and wouldn't do so.

These are, again, unrelated problems to the essence of the request, as the request is about rebranding, not dropping the package altogether.

So, I again reminded them that this is not our responsibility as an upstream to fix their problems.

They then 'suggested' us to add code to check if the user is running an outdated version, and then 'offered' that they will patch their existing packages and potentially Debian's and Ubuntu's as well, essentially moving the goalposts once again. They're expecting us to either phone home or somehow keep track of releases every six months.

If we were to phone home, we would need to cover more cases, such as bothering designers to find an appropriate way to display a warning to the user when they are not connected to the network or when the "gnome.org" domain is unreachable. This adds another dependency on the network for no reason.

This also adds more burden to translators: this is not a typical string where one needs to translate one word into another; the tone and vocabulary of a warning depends on the region, so translators need to adapt the vocabulary to ensure that the underlying meaning is not misinterpreted. In any case, I think it is fair to say that this is an absurd suggestion to a problem that has nothing to do with the upstream.

I lost my patience; I hostily replied that we as upstream do not care about how distributions operate, and, once again, reminded that all we want is for them to rebrand; a very simple request that was continuously red herred with bikeshedding, strawmen, whataboutisms, and moving goalposts.

When I posted that comment, I misinterpreted the message as I thought their 'offer' was them asking us to do their work, hence me stating that we do not care about how distributions operate.

The packager then replied: "If you don't care, then neither do we."; here, they are explicitly confirming that they do not care about Debian and the situation altogether. In a later comment, they stated: "probably requires GNOME Calendar to move away from free licenses" and locked the issue, which, once again, completely ignored the essence of this entire issue, but this time concluding with the 'you chose the wrong license' card.

Now, they were explicitly told what the problem was, have refused to act on it by continuing to shove their responsibilities onto us. The attitude went from doing something 'just because they can' to 'that should show upstream for hurting my feelings!', never mind the fact that we and Debian are the ones doing the hard work, which they are leeching off.

Addendum: Past visual and behavioral changes to Calendar while retaining the brand

What Mint did, in addition to generally shipping outdated versions of everything, the packager has conveniently ignored in their replies to the issue:

• Mint actively downgraded GNOME Calendar's version to a 2-4 years older version, to make it go from the GTK4+libadwaita version to the GTK3 version, making users needlessly experience hundreds of old bugs that had long been fixed by the GNOME Calendar developers
• Mint then forked libadwaita into libAdapta, and made their version of GNOME Calendar use that
• libAdapta is now years behind libadwaita in terms of features, based on version 1.5 of libadwaita while libadwaita is at version 1.9

This can be seen in various blog posts from Mint, such as the ones cited below:

In Mint 22 GNOME Font Viewer was removed and the following applications were downgraded back to GTK3 versions:

• Celluloid
• GNOME Calculator
• Simple Scan
• Baobab
• System Monitor
• GNOME Calendar
• File Roller
• Zenity

These applications are very likely to be forked in the near future, except for Zenity which we'll probably stop using altogether.

- https://blog.linuxmint.com/?p=4675

With the release of Linux Mint 22, GNOME Apps which used libAdwaita were downgraded back to their GTK3 versions so that they could continue to function properly in the desktop environments we support. This was a temporary solution until these applications either got replaced, removed, forked, or until we found a way to continue to use them.

- https://blog.linuxmint.com/?p=4840

libAdwaita apps and patches

Starting with Linux Mint 22.2, libAdwaita will be patched to work with themes. Support for libAdwaita was added to Mint-Y, Mint-X and Mint-L.

The following apps will be upgraded to their libAdwaita versions:

• gnome-calendar
• simple-scan
• baobab

libAdapta fork

In the scope of XApp and for our own projects, libAdwaita was forked into libAdapta

- https://blog.linuxmint.com/?p=4850

Trademark and free software

As explained above, this actually has nothing to do with free software; rather, this is a question about trademarks: Linux Mint is allegedly² (mis)using GNOME's name by redistributing unsupported builds while pretending that they are supported by us, and is actively misleading users to avoid supporting them.

Offending distributions use the 'you chose the wrong license' card because it is simultaneously very difficult to correct them as a non-lawyer, while being looked positively throughout the free software community. However, they know very well that looking at the situation from the perspective of trademark usage rather than software licensing would make it significantly harder to defend themselves, so naturally they opt into using (the incorrect) free software licensing as a gotcha.

Tone is irrelevant

The issue itself was originally calm and straight to the point. Half a year passed by and there was no response. Then, the packager was pinged, they chimed in, and changed the subject immediately. The tone shifted, and they took the easy way out by locking the issue and misleadingly stating that this is an upstream problem for choosing the wrong license.

In other words, you have two choices:

1. You kindly ask, and nothing happens apart from your own time and energy getting wasted for a considerable amount of time, with constant red herring or silence.
2. You start acting like a 'dick', and now they use this as an excuse to no longer communicate with you, all the while still refusing to address the underlying issue.

As an upstream, it is a lose-lose situation with hostile downstreams such as Linux Mint. Once they start packaging your software, they immediately burn their bridges implicitly. In order to show that they are 'good', they only pretend to care about the problem, and keep proposing 'solutions' that 1. have nothing to do with the underlying problem, and 2. put on significantly more burden to upstream without putting an equal amount of effort themselves.

The reason there are so little undocumented cases is because many maintainers who deal with hostile downstreams are usually indie-developers that have very little resources and energy to deal with these problems, and have very little to no understanding with trademarks and legality.

They get burned out, stop developing and contributing to free software, and (rightfully) lose hope for the Linux desktop. They do not make any of it public or make a fuss about the situation because they do not feel comfortable to be in the middle of a conflict publicly. All they want is to just enjoy providing goods to the world, but are unfortunately bullied by repackaging fetishists whenever they raise a legitimate issue.

Conclusion

To summarize all this, hostile downstreams have already gone as far as to burn their bridges with upstreams. Any upstream is at a lose-lose position no matter how kind or unkind they are. If they are kind, they will be on the waiting list for as long as governments put patients on the waiting list for medical care. If they are 'rude', hostile downstreams will use this tone against them. If upstream sends out a cease and desist letter, the free software community will start seeing them as the Nintendo of free software and conflate volunteers who are fed up with hostile downstreams, with corporations that sue every sentient being that breathes.

18 Jul 2026 12:00am GMT

Since the release of GIMP 3.2.4, we've been hard at work behind the scenes. We've been making fixes that will be included in the upcoming 3.2.6 stable release and adding tons of new features for the first 3.4 development version.

In addition, we've been mentoring our four Google Summer of Code (GSoC) students as they've been working on their projects. Since we just completed their midpoint evaluation, we wanted to share their progress with you all!

In alphabetical order:

Akascape¶

Project Description

Akascape started off their early work for GSoC by creating a new Vibrance filter in GEGL. This filter combines the existing Hue-Chroma and Saturation filters to more selectively adjust the less saturated sections of an image without increasing others. It was released in GEGL 0.4.68, so you can use it right now in GIMP!

Their main focus has been on improving the user experience with the Keyboard Shortcuts dialog. They plan to both improve usability while also adding new features.

Akascape's in-progress work already includes several big improvements such as a category list to quickly jump to relevant shortcuts, the ability to import and export shortcut "profiles", and efforts to make the dialog more friendly for a future GTK4 port.

In addition, Akascape did some early work on adding more adjustment layers to our PSD import plug-in, building off in-progress work by several contributors. His work would allow for importing Vibrance, Black & White, Photo Filter, and Exposure PSD adjustment layers.

Blezecon¶

Project Description

Blezecon has taken on the task of building the online infrastructure for a GIMP Extensions platform. Originally planned as part of GIMP 3.0, the Extensions platform would allow users to download third-party themes, brushes, plug-ins, and more via a package manager directly in GIMP. The local infrastructure has been in place for several years - this GSoC project is about developing the online submission process.

Blezecon has been working in the Extension repository and making great progress. His initial work involved cleaning up and correcting issues with the initial YAML script.

He then created a comment-based approval system in the repo. This will allow community moderators to easily inspect and approve new extensions through the same interface they use for responding to issue reports and review merge requests. Blezecon next developed a scheduler script that will monitor pending extensions, and once they have received the required approvals, automatically merge them into the Extensions repository for user access.

While infrastructure work is often not as visible to end users, Blezecon's GSoC project is an essential effort to getting the Extensions repository up and running for future releases of GIMP!

v4vansh¶

Project Description

v4vansh did some early bugfixes and improvements in GIMP beforehand. He fixed a problem where the thumbnail wouldn't update after changing image modes, and he corrected missing information in our manual page generation.

Since the start of GSoC, he has been focused on improving text handling in GIMP. His current big project is grouping fonts by family in the text widgets. In addition to better organization (especially with the infamous Noto fonts which have hundres of variants), this patch significantly reduces lag on systems with large numbers of fonts, as v4vansh's mentor Liam can attest. This feature is in final testing, and we hope it will be merged into the main codebase soon!

v4vansh has also begun experimenting with adding support for OpenType variable fonts. This would allow for much more sophisticated font and text work in GIMP. The initial work involves exploring both the functionality and the user interface to interact with it, and both will develop further as he continues to work with OpenType fonts.

Waris Maqbool¶

Project Description

Before GSoC began, Waris contributed some early work to GIMP. He updated our OpenEXR import code to load YUV images in color instead of in grayscale. The main focus of his project though has been with GEGL, our color processing engine.

His first project was implementing a GEGL version of the Sharpen filter. Sharpen is a simpler version of the Unsharpen Mask filter, a popular method of correcting blurry images. It was unfortunately removed from GIMP 3.0 due to it not being maintained and only working on 8 bit images. Waris has created a GEGL filter of Sharpen by doing comparisons with the 2.10 version. The recreated Sharpen filter will be non-destructive and will have an on-canvas preview, both improvements over the original.

You can see the in-progress merge request for comparison. We're doing some final reviews for optimization, but we expect it to be ready for a future release of GEGL and GIMP.

Waris has also begun working on a new Inner Glow filter for our PSD support improvement project. While GEGL already has an inner glow feature, it was not designed to be compatible with how it looks in Photoshop. As part of his work, he is also creating a generic curve editing widget to use for editing the PSD Inner Glow's settings.

We unfortunately had more great GSoC applicants than we were awarded available spaces. One student in particular continued contributing, so we'd like to highlight their work as well.

Harsh Verma¶

Harsh has been focusing on several different areas of GIMP. His initial proposal involved improving our unit testing suite. He is currently working to implement automated UI testing for GIMP. This is a challenging task, as interacting with the UI varies across platforms. He's already developed several tests that work on Wayland, which you can see at his in-progress merge request.

He's also improved our contributor infrastructure that integrating CI-Fairy into our pipeline. This feature checks to make sure contributor commits follow the proper format before merging, which makes our commit history easier to read and understand.

Harsh has also been working on more user-visible changes. He recently took on a user request to add more version information to our About dialog. This follows standard practice with other software, and makes it easier for users to find information that helps us troubleshoot problems. In addition, there's a handy Copy feature to easily grab the information for sharing. The code and UI have gone through several revisions based on developer and designer feedback, and it will likely be merged soon!

We've very proud of our student's contributions so far, both in code and in community! We're looking forward to you all getting the chance to try out their work in future development releases of GIMP, which we hope to have more information to share soon.

17 Jul 2026 10:00pm GMT

Update on what happened across the GNOME project in the week from July 10 to July 17.

Events

Victoria 💁🏻‍♀️🏳️‍⚧️ she/her announces

GUADEC is happening! Make sure to visit https://www.youtube.com/@GNOMEDesktop to watch the talks.

You can see what talks happened when here: https://events.gnome.org/event/306/timetable/#20260716.detailed

GNOME Core Apps and Libraries

Libadwaita ↗

Building blocks for modern GNOME apps using GTK4.

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

2 new features in AdwSidebar this week:

• Items can now have prefix widgets, in addition to or instead of icons. So it's now possible to e.g. have AdwAvatars as icons
• Sections can have header suffixes, same as AdwPreferencesGroup. This can be used to put a + or a menu button in there

Glycin ↗

Sandboxed and extendable image loading and editing.

Sophie (she/her) says

Glycin 2.2.alpha.7 has been released. This release brings:

• Better support for other platforms in libglycin including patches by Felix for macOS and Windows MSVC, as well as cross-compilation support by Anton. The CI now includes builds for libglycin on macOS as well as cross-compilation for Windows GNU (which is not yet fully functional).
• A refined pixel density API in libglycin to simplify its usage, including conversion of pixel densities between different units. There is now a merge request that makes use of it in gdk-pixbuf when loading or writing JPEG, PNG, and TIFF images.
• An option to disable the glycin sandbox by setting the environment variable GLYCIN_DISABLE_SANDBOX=i-know-the-risks. There is now also a test_disable_sandbox meson option to disable use of sandboxes when running tests for build servers that don't support sandboxing.
• Switching glycin's sandbox from an allowlist to a blocklist. This will simplify the feature a lot and should be sufficient since the seccomp filters are only a second line of defense behind guards like namespaces.

Sophie's work is funded by the GNOME Fellowship program. You can support the fellowship program via a donation.

GNOME Circle Apps and Libraries

NewsFlash feed reader ↗

Follow your favorite blogs & news sites.

Jan Lukas reports

Did a small release with all the things that piled up over the months. Lots of minor improvements to the html2gtk translation. Added a quick toggle to justify the article body. The local sync back-end powered by peer2panda technology didn't make it into this one, sorry.

Third Party Projects

Mikhail Kostin announces

Vinyl - music player with the best lyrics support, has been updated on v1.5.0! There is a lot of changes since v1.4. Over the month, I tried to do as much work as possible on the functionality and accessibility of the player, especially I did a lot for mobile form factor, Vinyl currently fully supports mobile devices with Linux.

Features include in this release:

• Added background playback, opportunity to hide Vinyl's window without stoping playback
• Added mono audio mode, opportunity to play the same on both sides of the headphones
• Added shortcuts for move through the lines of lyrics
• Added ability to save preferences after Vinyl was closed
• Fixed a bug when the user could restore the playist incorrectly several times
• Fixed work with large text

Today you can see the new version of the Vinyl on Flathub

For Void Linux users Vinyl also distributes on Community-driven repository blackhole-vl in native xbps package

Tanay Bhomia says

We just released Whisp 1.3.7, bringing a massive expansion to our built-in text macro engine!

Whisp is designed to be a friction-free scratchpad, and with this update, you can now instantly format and organize your notes without taking your hands off the keyboard. Simply type :: to trigger the new autocomplete popover, which is now case-insensitive and features rewritten spatial logic to perfectly align with your cursor.

Here are the new macros you can trigger instantly:

List Management: ::sort_lines_alpha, ::sort_lines_number, ::dedupe_lines, and ::remove_lines_empty Task Organization: ::checked_to_bottom (snaps all completed [x] tasks to the bottom of the list) and ::remove_checked Data Parsing: ::commas_to_list, ::lines_to_commas, and ::replace(old,new) Filtering: ::keep_lines_with(text) and ::remove_lines_with(text) Alongside the new macros, the app's core UI has been polished with a modernized, theme-aware "What's New" dialog and refined default window footprints.

Read full changelog

Flathub : Download Whisp Github : github.com/tanaybhomia/Wh… Donations : tanaybhomia.github.io/Whi…

Haydn Trowell announces

The latest version of Typesetter, the Typst editor for focused writing, adds one of the most requested features: manual preview zoom.

Typesetter is built around the idea that the application should get out of your way. By default, it automatically chooses a well-balanced editor font size and preview zoom level so you can start writing without fiddling with settings. Sometimes, however, you want a different view of your document while you work. Version 0.15 now lets you manually adjust the preview zoom, giving you more control when you want it while preserving a distraction-free default experience.

Get it on Flathub: https://flathub.org/en/apps/net.trowell.typesetter

Vladimir Kosolapov reports

Lenspect 1.0.6 is now live on Flathub

This release features proper background scanning with status updates in the Background Apps section. It also packs numerous under-the-hood fixes and optimizations, most notably a reduction in memory usage during large file uploads.

Since the last mention in TWIG, updates include keyboard shortcuts and quota usage notifications, alongside UI adaptability and accessibility improvements.

Check out the project on GitHub

Oleksii Tishchenko reports

Transition is a simple application for converting multimedia files to various audio formats, which helps you convert large (or small!) amounts of arbitrary files with automatic quality adjustment.

Transition supports converting to:

• OGG/Opus
• OGG/Vorbis
• MP3
• FLAC
• WAV

Get it on flathub

Victoria says

Version 1.0 of Tally has been released. This version significantly improves the app's layout, prevents scrolling from randomly changing a counter's values, and fixes many other minor issues. https://flathub.org/apps/details/ca.vlacroix.Tally

Gitte ↗

A simple Git GUI for GNOME

Christian reports

Gitte, a simple Git client for GNOME built with GTK4, libadwaita and Relm4, just got its 0.9.0 release! 🎉

The headline feature this time is history rewriting in the commit graph: you can reorder commits by dragging and dropping them, squash and fixup, drop commits, and cherry-pick, all directly in the graph and on several commits at once via multi-selection. If you just want to change a single commit, you can now edit it straight from the commit log.

Stashing got a thorough overhaul. There is now a single dialog to choose between tracked and untracked files and to add a message, backed by refined shortcuts (Ctrl+Shift+S and Ctrl+Shift+U) and a new stash action icon. Stashes can be renamed, they have their own context menu in the commit graph view, and they are shown directly above their parent commit.

A few new actions found their way in as well: "Discard all pending changes" in the working copy view and the sync-with-mainline dialog, and "Open in external editor" context-menu entries. Error toasts got a copy button, the branch name now shows up in the success toast when checking out, and a new setting auto-expands the staged and unstaged lists depending on whether they are empty.

On the UI side, context menus and menu toggles have been overhauled, the search bar is now always visible on the start screen, and mode changes, empty files and renames render much nicer in diffs. Drag and drop got a nicer animation, the sidebar badges got tooltips, the start-screen icon got a drop shadow, and the spinner backdrop and card styling are gone.

There is one security fix worth calling out: the resolved Git configuration is now written to a private, 0600 file instead of a world-readable one in /tmp.

And of course there is the usual pile of fixes: excludeFiles paths with a leading tilde are handled correctly and ~/.config/git/ignore is respected, the mainline marker on remote branches updates when the mainline changes, the upstream is set correctly, cherry-picking is only offered when every selected commit is actually off your current branch, its options are no longer hidden for non-merge commits, and opening a file in an external editor without a line number no longer passes an empty line number to the editor.

Under the hood there are fresh Serbian (thanks to Марко Костић), Slovenian (thanks to Martin Srebotnjak), Basque (thanks to Asier Saratsua Garmendia) and Finnish (thanks to Jiri Grönroos) translations, plus updates to the Chinese (thanks to Dawn Chan), Cornish (thanks to Flynn Peck) and Ukrainian (thanks to Yuri Chornoivan) ones. There is also a large refactor toward more declarative Relm4 UI and dialogs, a unified dirty-changes handler, a single abstraction for all config writes, less code duplication, more test coverage and updated dependencies.

Get it on Flathub, for macOS or have a look at the Code.

Gir.Core ↗

Gir.Core is a project which aims to provide C# bindings for different GObject based libraries.

Marcel Tiede announces

GirCore released version 0.8.1 with several bugfixes for the source generators handling subclass generation and compsite templates.

Crosswords ↗

A crossword puzzle game and creator.

jrb reports

Crosswords 0.3.18 has been released! This our biggest release to date, and it's a really good one. The game features a refreshed visual appearance with new artwork and overall design. It's also fully adaptive, so supports mobile form factors. The grid editor now supports information layers to give immediate feedback on how grid creation is going. Both also now have a built in magnifier to make cells easier to read.

Release announcement: https://blogs.gnome.org/jrb/2026/07/15/crosswords-0-3-18-style-and-substance/

Available on Flathub: Game | Editor

RustConn

Anton Isaiev says

RustConn 0.18 Released

As before, RustConn is a connection manager, an address book that orchestrates SSH, RDP, VNC, SPICE, Telnet, and Zero Trust sessions in one GTK4/libadwaita window. Below is what landed between 0.18.0 and 0.18.10.

The headline this cycle is embedded RDP going native. The built-in IronRDP client now supports the EGFX graphics pipeline with H.264 decoding (via OpenH264, runtime-loaded), RD Gateway tunneling (MS-TSGU over WebSocket), and zero-latency input delivery through tokio::select!. That means clipboard, shared folders, printer redirection, audio, and HiDPI scaling all work through a gateway connection, no external FreeRDP process needed. On a 4K display the pixel conversion is 3× faster thanks to auto-vectorization of the RGBA→BGRA path.

A few other highlights:

• Split view for everything. Split panels now work for any in-process tab, not just terminals. Embedded RDP, VNC, and SPICE desktops can be split, mixed with terminals, dragged between panels, and their toolbars adapt to narrow panes automatically.
• Network resilience. RustConn monitors interface changes via gio::NetworkMonitor, closes stale SSH ControlMaster sockets on the spot, skips reconnects behind captive portals, rate-limits during VPN flaps, and reconnects embedded sessions after a network switch without user action.
• Headless core. rustconn-core default features are now empty: a pure domain library with no GUI or keyring dependencies. The CLI ships only management commands by default; desktop features are opt-in. CI and Codex builds are faster and smaller.
• HiDPI. A new "Native (full HiDPI)" display scale option follows the monitor's live scale factor, so the remote desktop stays crisp across monitors without manual percentage selection.
• External-session tracking. VNC/RDP/SPICE sessions opened in an external viewer no longer leave dead tabs; they're tracked in the sidebar with a status emblem, right-click to disconnect or detach.
• Nix flake. nix run github:totoshko88/RustConn works out of the box for NixOS users.
• Security & memory hygiene. Vault password intermediates are now Zeroizing across all 9 backends, clipboard password is zeroized, pre/post-connect tasks have a 60 s safety timeout, keyring saves time out after 5 s instead of freezing forever, and FreeRDP bumped to 3.29.0 (22 advisories fixed upstream).

~60 bug fixes across the cycle, including: SSH agent/FIDO2 key selection actually saving, "Save & Connect" from the wizard actually connecting, Enter in the sidebar opening the selected connection, Telnet templates showing the right editor page, 8-bit RDP audio no longer playing as noise, the VNC embedded client delivering remote clipboard locally, Zero Trust validation before save, workspace restore for splits/Local Shell/async sessions, and many more.

Full changelog: https://github.com/totoshko88/RustConn/blob/main/CHANGELOG.md

Thanks to Jürgen Hörmann for contributions this cycle. This project is built entirely on personal enthusiasm and free time. There's no company behind it, no grants, just evenings and weekends. If RustConn saves you time at work or you simply like what it's becoming, consider supporting the project financially: https://github.com/sponsors/totoshko88. Stars, bug reports, translations, and spreading the word help just as much. Every bit of feedback keeps the motivation going.

Homepage: https://github.com/totoshko88/RustConn Flathub: https://flathub.org/apps/io.github.totoshko88.RustConn Snap: https://snapcraft.io/rustconn

Shell Extensions

Tomáš Gažovič reports

A new version of RSS Feed is out on EGO. The extension brings RSS/Atom feeds into the top bar and system notifications. This release was a big internal rework: feed refresh no longer stutters the shell (profiled with GSE Profiler, a tool I built along the way), the menu finally works on light themes like Yaru, and notifications can be grouped by source on GNOME 48. If you ever wanted RSS reader directly in GNOME Shell, this is the version to try. Full write-up: what changed and what I learned.

Anton Isaiev says

Browser Switcher updates: GNOME 1.2.5

The big internal change: browser detection moved from manually parsing .desktop files and spawning xdg-settings to native Gio.AppInfo and Gio.AppInfoMonitor. That means fewer external dependencies, less code, and the menu rebuilds on open so a freshly installed or removed browser shows up without restarting the Shell. Duplicate entries (like google-chrome.desktop vs google-chrome-stable.desktop) are now deduplicated by display name. Flatpak user-installed browsers are detected. Signal cleanup uses connectObject()/disconnectObject() as the review team requested, so no leaked handlers on disable. Supports GNOME Shell 45 through 50.

GNOME: https://extensions.gnome.org/extension/8836/browser-switcher/ Source: https://github.com/totoshko88/browser-switcher

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!

17 Jul 2026 7:32pm GMT

We take advantage of loading systemd system credentials based on smbios type 11 strings and QEMU's vsock feature. Here is the list of recognized system credentials.

The important bit passing down the following argument to qemu

$ qemu-system-x86_64
  # ...
  -device vhost-vsock-pci,guest-cid=$cid \
  -smbios type=11,value=io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=$base64_ssh_key 

libvirt allows setting smbios11 as <oemStrings> and defining virtual sockets.

Under GNOME boxes, go to the VM configuration. The important bit is setting a smbios under os, adding a vsock device and the sysinfo domain. E.g.

<domain type="kvm">
  <!-- ... other domains -->
  <os firmware="efi">
     <!-- ... other os info -->
     <smbios mode="sysinfo"/>
  </os>
  <sysinfo type='smbios'>
    <oemStrings>
      <entry>io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=$base64_ssh_key</entry>
    </oemStrings>
  </sysinfo>
  <devices>
    <!-- ... other devices -->
    <vsock model="virtio">
      <cid auto="no" address="$cid"/>
    </vsock>
  </devices>
</domain>

Here $cid needs to be replaced by a numerical value bigger than 2 and

$base64_ssh_key is the base64-encoded public SSH key, we use $cid=3 here. One can encode a public SSH key via

<~/.ssh/id_ed25519.pub base64 -w0

Ensure you can decode it back before proceeding!!

echo -n "output from above" | base64 -d

Then inside of the VM, verify the smbios 11 key is visible,

$ run0 systemd-analyze smbios11
io.systemd.credential.binary:ssh.ephemeral-authorized_keys-all=$base64_ssh_key…
1 SMBIOS Type #11 strings passed.

on the guest's journal one should see:

$ run0 journalctl -b -g 'ssh.ephemeral-authorized_keys-all'
Jun 18 00:11:06 gnomeos-11e6-75db systemd[1]: Received regular credentials: ssh.ephemeral-authorized_keys-all

and one can verify it via:

$ run0 systemd-creds --system list
NAME SECURE SIZE PATH
ssh.ephemeral-authorized_keys-all secure 97B /run/credentials/@system/ssh.ephemeral-authorized_keys-all
$ systemd-creds --system cat ssh.ephemeral-authorized_keys-all

Now that everything is set, and the sshd service is running inside the VM:

systemctl enable --now sshd.service

one can ssh into the VM via:

ssh $user@vsock/$cid

where $user is the username inside of the VM and $cid as above, in my example:

ssh msandova@vsock/3

This requires systemd-ssh-proxy on the host, should be included in v257 or newer.

Note that scp has a slightly different syntax, e.g.

scp $FILES msandova@vsock%3:$PATH

15 Jul 2026 9:04pm GMT

Greetings!

Time for a new Crosswords release. This is a massive one with over 1,000 changes from 18 different contributors, and is the biggest release I've done to date! This features major improvement to the appearance of the Player, and to the usefulness of the grid filling code in the Editor.

Player: Artwork and Appearance

I made a real push this cycle to improve the appearance for GNOME Circle inclusion (tracking bug). We made almost too many usability and appearance improvements to mention! The artwork also got a major improvement with a great intro screen, new icons, and a fabulous looking "How to Play" screen. Take a look:

The artwork also is responsive to the libadwaita accent colors. Thanks a ton to Tobias, Hylke, and Gnoman for their fantastic work on this. It makes the game look so much more professional.

Update: Also, I have to plug Hylke's fantastic work on improving icon's across the whole ecosystem. I'd encourage people to sponsor him if you have the means!

Mobile mode

As part of all the work for Circle we adopted more of the recent libadwaita widgets. This basically gave us "mobile mode" for free. It's not perfect: we're missing some gesture support and the behavior has some quirks. I could also use more support in GTK as well - we're missing a chunk of the expected mobile API. But for something that wasn't worked on intentionally it's really impressive at how well the adaptive widgetry works in libadwaita.

In addition, sp1rit did a GTK Android build of Crosswords as a proof of concept. It's missing some crucial elements - namely python for the import pipeline - so you can't play many games with it. But it's amazing that it works at all.

Magnifier

I've been jealous of a feature that exists in the fabulous Typesetter app, namely right clicking on the output it will bring up a magnifier. I mentioned this to Toluwaleke (of Mutter GPU Reset fame), and he quickly wrote the same for Crosswords. It looks great, and cleverly reuses the ::snapshot() method to do the zoom. It will work with the mouse, or can be toggled by the keyboard. Take a look:

Editor: Layers and the AC3 Solver

For this release, we closed one of the biggest gaps the Editor had by adding information layers to the grid. This is a little hard to explain, so a demo might help. The layers are used to indicate different challenges in building a grid, and are required for any serious crossword editor. We support the following layers:

• Spell Check: Indicates when the word in a slot isn't in the dictionary
• Unchecked Cells: Indicates slots that are 1 or 2 cells long
• Heatmap: Warns of cells that are hard to fill
• Unfillable Cells: Indicates that there are no dictionary words that fit a slot

The spell check and unchecked cells jobs were straightforward to implement, but the heatmap/unfillable cell jobs are not. Fortunately, GSoC student Victor wrote a Design Doc last summer to propose a way to calculate these. He ran out of summer to implement it, so I picked it up this past Spring. It took some time, but I'm really happy with the results. It's not fast enough to be synchronous, but does run in ~200msec, which means we can run it every change. Given that some other apps we surveyed took seconds or even minutes to complete, I'm really pleased with the performance.

Additional Editor Features

• As part of her GSoC project, Laureen wrote EditDateRow modeled after AdwComboRow. This is much more convenient than a raw entry. We're adding more custom data entry rows that go with the libadwaita set. Let me know if you find this one interesting and want to use it and I'll clean it up for general consumption.
• I had a user testing surprise, as it turned out the histogram was actually useful for setters. Certain sites won't allow too many three letter words, and want a good letter distribution. As a result, I cleaned it up and made it more prominent.
• I've had a skip list for the WordList for quite some time, but it was only used for autofill. It's now used more widely, and can save/load from disk.

What's next?

I have a number of planned features for next time:

• I need to give the word list code a refresh. I added support for word removals but need to let users add them as well. In addition, I want a custom word list import feature.
• We will land code for the vocab puzzle GSoC project.
• There are two new GTK features I'm really looking forward to adopting: Snapping and animated SVGs. The latter is going to be amazing!
• And hopefully, I really hope that the next release is the release where we finally get into GNOME Circle. Fingers crossed.

Thanks for reading!

15 Jul 2026 1:00pm GMT

I am implementing a new type of crossword puzzle in GNOME Crosswords this summer. The current options are static crosswords of 'known' location. My project does the opposite, where it takes the words and places them wherever we can get the maximum amount of connections between the words. The pinnacle of this is a DFS backtracking algorithm because we want the words on the grid to be malleable in their placements in order to include the next word going down the list.

Previously, what I had done was attempt to erase the word letter-by-letter recursively writing NULL to each cell. However, this removed every element in the string, including the letter shared at a node between two words, leaving a gap in the word left in place.

My most current version instead focuses on state preservation. Before we even write a new word to the grid, we read the existing state of cells with focus on those connections. Now when the recursive function attempts to place a word that ends up being impossible to connect with the current setup, we look for those '?' characters, erase the string, and rewrite the cushioned letter to leave the other word fully intact.

Imagine a board with CAT written across the center, and we want to place MACAW on the grid vertically. Before the algorithm writes MACAW, it inspects the board at the calculated intersection point(s) and reviews the cells of the string length.

Cell 1: Empty, Cell 2: Empty, Cell 3: C, Cell 4: Empty, Cell 5: Empty.

The board saves this state in memory using a '?' in place of the empty cells as '? ? C ? ?'. Hypothetically this makes our board look temporarily like this in memory:

?

?

C A T

?

?

MACAW is written to the grid and then checked in the next recursive function call to ensure if it can be kept or not in that hypothetical place. If it runs successfully, we leave it as is:

M

A

C A T

A

W

If it returns false, we need to backtrack and erase MACAW. Rather than totally erasing the word like before, we send the ? ? C ? ? state back to our overlay function - which is responsible for writing to the grid. If it sees a '?', it empties the cell. If it sees a letter, it rewrites it. That way we are only backtracking and erasing the word creating an obstacle in our program. MACAW is erased, CAT remains there for the next word to be attempted.

14 Jul 2026 1:04pm GMT

It's been 4 months since I was officially laid off. It's been good and I can honestly say I'm doing my best work.

What I've been up to

• Bobby has been accepted into GNOME Circle
  • I'm back as a GNOME Foundation member
• Started the weekly app icon initiative
  • 20 app icons created so far
• Good progress on the SparkleShare reboot in Rust
  • The new CLI mode is ready for testing

Happy to announce that with your help I've reached the first milestone of 64 monthly sponsors.

Thank you! More good stuff is coming. :)

13 Jul 2026 12:00am GMT

Update on what happened across the GNOME project in the week from July 3 to July 10.

GNOME Core Apps and Libraries

Glycin ↗

Sandboxed and extendable image loading and editing.

Sophie (she/her) announces

Version 2.2.alpha.6 of glycin is now available. The version brings support for reading and writing the pixel density in JPG, PNG, and TIFF images. The data is now also accessible via the "Image Properties" in Loupe. A prominent application of this feature is to store the DPI used when scanning an image, which then allows users to print the scanned image in the same physical size as the original document. This has been one of the last features that was missing to achieve feature parity with gdk-pixbuf, which we plan to replace with glycin. Support via gdk-pixbuf glycin loaders will be added soon.

Glycin now also reads OpenEXR images that use half precision floats into the same memory format, saving half of the memory compared to the previously used single precision floats. Support for the Radiance HDR format has been added as well.

The lcms2 library has been dropped in favor of moxcms, which is written in safe Rust and improves the performance for images with ICC profiles noticeably. Internally, there is now a mechanism for a loader to report if ICC profiles or CICP (HDR instructions) should be preferred, since this differs between image formats.

Sophie's work is funded by the GNOME Fellowship program. You can support the fellowship program via a donation.

GLib ↗

The low-level core library that forms the basis for projects such as GTK and GNOME.

Philip Withnall says

The default network monitor in GLib, a netlink implementation of GNetworkMonitor, has been significantly updated by Sorah Fukumori to improve its performance. This will particularly help on systems with large routing tables (like servers), but should benefit all users. More details in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5222.

Emmanuele Bassi says

GLib now requires a C11 toolchain to build itself, and to build projects that depend on GLib. All supported compilers-GCC, Clang, MSVC-are compliant enough already, so nothing should change for GLib users. More details, and future plans, in https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3574. Also, you can always check the toolchain requirements in the GLib repository.

Miscellaneous

Sophie (she/her) announces

July is Disability Pride Month! I used the occasion to write a blog post share my thoughts on accessibility in GNOME and the current state and potential ways forward, like establishing a Accessibility Team.

• Accessibility in GNOME

GNOME OS ↗

The GNOME operating system, development and testing platform

verdre reports

We published a blog post announcing a new project as part of this year's Prototypefund to improve testing and development workflows on image-based OSes like GNOME OS.

As part of this we'll build a new app (tentatively called Test Center), to install and manage experimental versions of apps and system components (think Apple TestFlight, or the old Mozilla Labs), along with a number of other improvements to the system component developer story.

If you're a developer using GNOME OS we'd love to hear your input on this! What is currently most annoying when developing and testing your software, which workflows are awkward in a fully image-based world, what are tools you're missing, etc.

https://modal.cx/blog/image-based-for-developers

Third Party Projects

Sjoerd Stendahl announces

This week I released on update to Lockpicker, a new application to recover passwords from their hash. On top of some minor UI tweaks, Lockpicker now allows you to import multiple rule files simultaneously. Also, a nice new quality of life update is that you can now undo your action when you removed a module, rule or wordlist.

Note that you are going to have to provide your own hashcat rule files to Lockpicker, these are widely available at different Github repos. A future update in Lockpicker will focus on creating rules yourself straight from the UI.

Get lockpicker from Flathub!

Phosh ↗

A pure wayland shell for mobile devices.

Guido reports

Phosh 0.56 is out:

Phosh now supports hiding and disabling applications. This is useful on immutable systems where software from the base images can't be uninstalled. We also added a load meter status bar plugin that can be enabled to show the current system load as a small graph. The Wayland compositor phoc now uses wlroots 0.20.1 and the on-screen keyboard now allows to set keyboard layouts per application. This can be used to e.g. force a terminal layout for the text editor you're using for programming on your phone 🤓. We also added key-repeat for keys in the shortcuts bar like ⬅️⬆️⬇️➡️.

There's more - see the full details here.

Flare ↗

Chat with your friends on Signal.

schmiddi announces

Flare version 0.21.0 was released this week. Besides fixing linking (which broke on the latest version of Signal), this release contains a new backend-library for the Signal integration, flare-backend. This should make maintenance as well as developing new features for Flare a lot easier in the future. As an example, this release fixes some weird behavior with edit messages, and adds support for group labels. I have written a short blog-post introducing flare-backend if you are interested in reading more about it.

Shell Extensions

amritashan says

Automatic Theme Switcher ↗

Automatic Theme Switcher is a GNOME Shell extension that switches between light and dark themes based on the sun at your location - sunrise/sunset, dawn/dusk, golden hour, or your own custom times. Set your location manually or detect it approximately with one click.

This week version 11 landed on extensions.gnome.org, adding support for GNOME 50 (the extension now covers GNOME 45 through 50). It follows a major update that brought per-monitor brightness control, including external monitors via DDC/CI, gradual brightness transitions that ramp your screens gently down for the night and back up for the day, a manual override that respects your Quick Settings toggle instead of fighting it, Night Light synchronization, and a live countdown to the next switch in the preferences window.

Source, issues and feedback: https://github.com/amritashan/gnome-shell-extension-auto-theme-switcher

Christian W reports

OmniPanel is an extension that provides advanced Multi-Monitor window management to improve productivity.

It features smart-autoplacement of windows in configurable zones. It also renders the Gnome top bar on every screen (something that is not yet native to Gnome today)

Features:

• Top bar on every active screen, including active Extensions
• Window tiling with Zone designing and auto-placement
• Stack specific windows in Zones
• Auto-tiling capability without needing to draw zones
• Use either the mouse or hotkeys for switching/moving

To install, find it via "OmniPanel" in Extension Manager natively.

Source: https://github.com/cwittenberg/omnipanel

Install via Gnome extensions page here: https://extensions.gnome.org/extension/10049/omnipanel/

Youtube demo (with audio): https://www.youtube.com/watch?v=c7JNV20OV8k

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!

10 Jul 2026 7:49pm GMT

GIMP is Free and Libre Open Source Software, but none of it is possible without the people who create with and contribute to it. Our project maintainer Jehan wanted to interview the volunteers who make GIMP what it is, and share their stories so you can learn more about the awesome people behind GIMP!

Early interviews from co-maintainer Michael Natterer and Michael Schumacher were published shortly after the first Wilber Week. The remaining interviews from this event, about Simon Budig and Øyvind Kolås were published years later as a revival of the series. While these interviews are a bit old and reference outdated versions and features of GIMP, we believe they still have value and show the evolution of our community.

This next interview is the first one recorded at the 2017 Libre Graphics Meeting in Rio de Janeiro, Brazil. The subject is Nara Oliveira, co-founder of Estudio Gunga. She is a Brazilian artist and advocate who uses free software exclusively to develop professional works in many fields, including design, illustration, and animation.

This interview took place over April 21 - 23, 2017. In addition to Jehan and Nara, Simon Budig, and Aryeom Han were also involved and asked questions.

Jehan: Hello Nara. Can you introduce yourself to the people?

Nara: My name is Nara Oliveira. I am a Brazilian designer. I am from Brasília, the capital. The city name is Taguatinga. I study design and today I work with free software. I have my own company with some partners and we work in audio, video, design, and animation.

Jehan: What is the name of your company?

Nara: Gunga. Gunga is an instrument from Capoeira. We have the berimbau with the "calabash", I think - it's an instrument from Capoeira.

Jehan: Okay. From what we understood, you mainly use free software

Nara: Yes.

Jehan: Mainly, or only?

Nara: Only.

Jehan: And which ones in particular?

Nara: I use GIMP, Inkscape, MyPaint, sometimes Krita - I've tried it - Scribus, FontForge, FontMatrix, and others like everybody uses.

Jehan: Do you use Linux?

Nara: Yes, Arch Linux.

Jehan: So full free software from start to end! Okay, and why do you do this?

Nara: When I heard about free software and Linux, I was working in a cultural space. I was working with theater and with drawing, and we already have that culture of sharing things and sharing knowledge. So when I met these guys in free software, they told me about what GNU and Linux were and the philosophy - and when I heard about it I fell in love with it. Because I already think that way, and so free software is applying what I think is right onto software and onto technology. So for me it just makes sense.

So I started to use this software. In the beginning it was difficult to make the transition, but with some time I got into it.

Jehan: So you made a transition from proprietary software?

Nara: Yes, from proprietary software to Linux.

Farid: When was this?

Nara: When? Ah, let me count…

[group laughter]

I was not finished studying then, so like around 2006 or 2007 I started. I really started to use Linux and everything for working in 2008, for everything.

Jehan: So you studied design in university?

Nara: Yes, in university.

Jehan: With proprietary software?

Nara: Yes, with proprietary software only. But my university was not so focused on software. In five years of studying, we only had one class about software. And as the class went on, everyone already knows how to use it! So it's like a class that has to be on the curriculum, but it's not like you have to use - it's more like conceptual.

Simon: Something I do a lot is that - I'm a software developer mainly, so I do a lot of my own tool development. Like I have a specific problem and I know there is an algorithm in my mind that I know would solve the problem (or might solve the problem), so I start implementing my own tools for very specific, very weird tasks, because I can't do it with GIMP.

Nara: I would like to do that!

Simon: So this is what I wanted to ask - do you have programming experience? Do you have an idea of what it means to develop software?

Nara: No, but I think I have an idea - but I do not develop programs. I've studied a little, but it's not like I can do something. I can see the code lines and know more or less what's happening, but I can't write lines by myself.

Jehan: You've told me that sometimes you will see some scripts and guess what it can be, and change the numbers…

Nara: Yeah, but more in insights and not in the programming itself.

Jehan: Since we're doing this interview for gimp.org, what can you tell us about GIMP? How do you like it? How do you hate it? Tell us everything!

Nara: [Laughing] The first thing is, I like GIMP. I use it a lot. My work and style is more vector, but I use GIMP a lot and I like it.

When I made the transition to free software, until today one thing I didn't like is that you don't see the effects. You have do something, turn back, "Oh no!" - I have to change two, three points here, then I have to undo and do it again and come back. For me, it's one of the things that makes the work not fluid.

I'm so happy to see GEGL on-canvas effects.

[Editor's note: This feature was already implemented in the development version of GIMP 2.10, officially released about a year after this interview.]

Jehan: So, some other comments on GIMP?

Nara: Yeah, I really like it but, for example, I have some problems with my tablet. When I bought my first tablet, it simply didn't work on GIMP. And I think it's because of that, I use MyPaint. Because I have to work, and I have to work right now and the pressure doesn't work, so what can I do with my tablet - so I found MyPaint, and I started to work with MyPaint, and it's because of that I use it. Not because I think it's more powerful than GIMP - it's just because of that. At the time I liked it, and today I still use it.

[Editor's note: GIMP 3.0 improved many issues with tablet support that were mentioned here.]

Jehan: So MyPaint is your main software?

Nara: For drawing, yeah. Because I am a designer, but I'm an illustrator too. So for illustration I use MyPaint, just for that. For small drawings, I use vectors in Inkscape, and so on.

I use GIMP more for photos, for editing, composing, correcting photos.

Jehan: Yesterday when we spoke, you had this nice example of a job you did with Scribus. Like your first job with free software, I think?

Nara: No, my first book.

Jehan: Ah, your first book, not your first job with free software. Could you tell it again, now that we're recording?

Nara: I was called on to make a big book, like three hundred pages. There was little time to do it, like three, two weeks. I am from Brasília, and they said you have to do it here with us to get it quicker. I traveled to Bahia to do it, and when I arrived there, there were two other designers. It was funny because I worked in Scribus, one worked in Corel Draw, and the other one in InDesign. So you had three designers, three different software.

Jehan: And three different operating systems.

Nara: Yeah, and three different operating systems, and we had to do one book, the same book!

So we met each other and said "Okay, let's do it!". We separated the book into pages, so I would do the first one to 100, the other designer would do 101 to 200, and so on. And we together figured out how the design of the book would be, and the rules to make each part feel like the same book.

So we started, and just like that, I finished first! I was worried, because I had not used Linux for too long, and if there was something wrong in the software or in the distribution, I would not know how to fix it. One of the designers had Mac and the other had Windows and I was so worried.

But it went well and I finished first - and it was very encouraging for me. It's just a tool you know? I can do it, he can do it, she can do it - everyone can make it, so I was very happy. Because in the beginning I was worried about everything going wrong, and that there would be problems when I saved the PDF and printed it, but it was all okay.

The book was about experiences with, we call it here "apprentice to Griô". It's from the French language, because it came from Africa but a country that speaks French.

It's like an old master who teaches the people around them, the community, something - knowledge about herbs, which can be medicinal herbs, or teaches about techniques about how to construct instruments, or make music, or dancing - like masters of Brazil, of all Brazil. So it's because of that it's a big book!

Years later, in the north of Brazil, when the waters came and filled the houses in the city - a flood. I was seeing that on the TV there was an old lady with her flooded house beside her, everything destroyed. And she had that book in her hand. She was crying because her house was destroyed, but she had the book, and she was happy she still had the book even though she didn't have her house anymore.

So it was a meaningful project, and it was the beginning of my using Scribus.

Jehan: Are there things sometimes you feel you are not able to do with free software? You already answered this yesterday, so I'm just asking again to hear you saying it.

Nara: When I see art - art is everything, design is everywhere - I can't see something and think about "I can't it do with free software". I can do it - maybe I can't do it because of my creativity or because I don't think about it, but technically I can do it, you know. We have the tools to do it. We have other ways, but we have the tools I think - in my area of design.

Simon: What would interest me is, you mention that you use quite a lot of different tools, like GIMP, Inkscape, Blender, Scribus -

Nara: Blender not yet, though I started animating in the timeline. In the movie that we showed, the first one that was in 2D, I animated parts of that.

Simon: But there are a lot of different tools that you and your colleagues use. When you start a project, do you pick one of the tools and stick to it, or is more like you start using one tool then transfer the result to a different tool?

Nara: Yes, it was like each tool was like a room of a house. I live in the house, there's a lot of rooms, and sometimes I'm in the living room, other times I'm in the bed room, other times I go to the kitchen. It's like I have a bottle, and I take the bottle here and there.

I don't choose the software. I plan the project, I think about it, and think "How am I going to make this?" So I will start drawing in MyPaint. But I need it to be a vector, so I save it, open in Inkscape and add a vector. But ah, I need an image in the background. So I open the image in GIMP, I work with the image there, then import into Inkscape, okay. But oh, now I have to print it. So I save what I can save in vector I save in vector, and what I can't save, I export. And I go to GIMP, transform it and edit it, and I take everything, go to Scribus, put them together, and make a PDF. More or less like this. I'm always going back and forth between the programs.

I think it's very complicated, but for me it's very simple. But when I teach things like that it sounds very complicated.

Jehan: Do you have any questions, Aryeom?

Aryeom: I feel like I am in her head. I totally understand - I work the same way. Maybe later if I have any questions I'll ask.

Nara: I learned everything by myself. So I don't like tutorials, you know?

Aryeom: You don't like tutorials?

Nara: Yeah, I don't have the mind to read or watch them. I learn all by myself. I think my way of working is just my way, because I learn by myself. And sometimes I get in touch with people who use the software too, I like to watch them because people do things very different that I do, and things more easily. And sometimes I teach the software to someone, and in two weeks or three, I go to see what the people are doing. "Oh my God, I'd never think of that way!". It's very fun because of this.

I don't like to do workshops because of that. I think my style of work is very crazy. But we can talk about it!

Jehan: So right now you have a big animation project. So maybe can you speak about it?

Nara: Well, Farid is the director. He writes the script. I am the art director, but I also help him with the script and doing all the storyboards. I do it in MyPaint. I was a little worried because I've never done a storyboard before. So I study a little, see other's storyboards, and make it for the animation. And we are talking with people who want to work with us on the animation - and I was happy because people always say "You have a beautiful storyboard!". I was worried about that.

I think we are, I don't know, opening ways. Because we are not a 3D studio but we want to do 3D animation, so we have to contact on a lot of other people in Brazil and Latin America, and even in Europe. It's been like a dream to make it. And we want to make it very fine, very good, because today if you are seeing bad 3D, then you don't watch it. Because you have Pixar, you have Disney, you have a lot of others. I don't think that we'll be like Pixar, but we have to do something very good and great to be seen, you know? I think this is our goal. We want to make something very nice, very good that everyone wants to see.

We're telling Brazilian history of Quilombo, when there was slavery. Some slaves ran away and made a tribe, a community of their own and lived there. And these communities survive until today. And some of them have a lot of different cultures. It's like they're isolated. And the story is about one of these communities. In Brazil the agriculture is taking the lands of these people, because they have a paper that says "We own these lands", but actually these peoples have been there for 300, 400 years.

So we are telling the story of a girl who lived in a community like this. And they're being pressured to go out and leave their lands. The story is a fiction, but it's based on real facts. This is the history. It's going to be like 10 minutes, it's a short one, but it's a real movie and after it's finished, we want to continue it. Make like episodes or a long movie - it's just like a pilot. But we need the pilot to get a bigger step.

Aryeom: I feel so moved, because our ZeMarmot project is also like this.

Nara: Here in Brazil there's a law, I'm not quite sure, that for free television and private television, 50% of programs have to be Brazilian programs. Because it's all foreign programs, so the government says that 50% have to be produced here in Brazil. So I have a lot of opportunities in that way for animated series.

Jehan: So you plan to distribute on TV.

Nara: Yeah.

Aryeom: Why did you choose 3D? Why not 2D?

Nara: Because we love it! We really love 3D, we're really passionate. We started using Blender, even for 2D, but we want to go to 3D you know. We have some experiences, and we like the visuals of the movie - we actually don't work with 3D, but we want to. A lot of people do that - I think 2D is less expensive and -

Jehan & Aryeom [in unison and laughing]: I don't think it's less expensive!

Nara: No? We like 3D. We want to make it - it's so popular for the kids, for everyone. We want this movie not to go to the festivals and stay there. A lot of good films here are made this way. The very good films go to the festivals, earn their prizes, and no one's ever seen the movie. "Oh you've seen that movie? No!". It will never go to the cinemas.

We want it to have the chance to become popular, you know, a lot of people really watching it. And 3D has this affection, people really like these.

Jehan: I know you said you also appreciate Creative Common licenses and stuff like that, so is this movie going to be under such a license?

Nara: Yes, it's going to be an open movie! You can take the characters and make another animation by yourself. If you want to take everything, the characters, the background, everything, and animate another story, you can do this.

Jehan: Which license?

Nara: We haven't thought about it yet, but the kind of license where you can make anything.

Simon: You said 3D. I sometimes have the impression that 3D in some way is more limited in what you can do artistically compared to 2D.

Nara: Yes, it is.

Simon: So this is not a factor for you?

Nara: No. Because in 3D, it's like you said. If you're doing a 2D animation, I don't know, you can do a lot of types of techniques. Like it can be black & white, it can be color, or so many types - it's like art in stop motion. 3D is different - you have a character, and you have the scenery, and the scenery is just the scenary. You can make some tricks with lighting and shading and colors, but it stops there. It's an artistic limitation, I agree with that.

Aryeom: In your team, no one had any experience making 3D animations?

Nara: I animate, but I know how to take the characters and make them move. But I'm not an expert. Farid knows that too and know how to make a 2D animation in Blender. But 3D is a new challenge for us.

Jehan: I think also the question was, you are a designer so you usually work in 2D. So we would expect something who draws would want this drawing to come to life, than just doing the drawing and give it to someone else to make the actual final thing.

Nara: I have difficulties with this. I get tired of drawing very quickly. I can't imagine myself drawing the same character more than, I don't know, 10 times. I think I would die if I did that.

Aryeom: Haha, I'm dying!

Nara: It's like my style. This book was difficult to me, because I had to draw the characters the same. They have to look the same every time I draw it. I don't like that. I like to do one drawing and it's over. They have to repeat and be the same. I like the work, but the process of doing the same thing is difficult for me.

Jehan: So you prefer to just draw something and let someone else repeat it again and again.

Nara: Yes, like the computer!

Aryeom: To make a series, an episodic drama, it's easier to make in 3D. For long form, it's good I think.

Jehan: Yes, for long form, but for short movies it takes longer due to preparations.

Nara: So it's not my kind of thing.

[Nara hands out a book]

Nara: It's by a friend of mine who wrote the story and he asked me to make the drawings. I don't do a lot of kid stuff, but I like it. And it invites kids to draw at the end of it. It talks about what city do kids want to live in, and what city we want for ourselves. We have a lot of problems in the cities here, and I like the idea of book, to let kids dream about the city because we want that dream to come true.

Aryeom: What about Gunga's future?

Nara: Ehh, I expect in the future that we have more people working with us. And we have more companies work with us with free software, you know. I'd like to get larger but not too larger. Because I want my life too!

Aryeom: Wise!

Nara: But I'm happy now because last year two new people joined the studio, and it's a lot more fun to work with more people. We exchange experiences, and I think I want to grow in that way, to get a little bigger and get more partners. And work with more cinemas! It's more difficult because it's expensive to work with cinemas, working with animations. We like to do more for ourselves. We make a lot of productions, videos for other companies, for the government, so we'd like to do more for ourselves - like our stories, less for them, more for us.

Jehan: Okay, maybe the last question unless someone has something. Do you have any requests for GIMP developers? Other than on-canvas preview because we already have it!

Nara: I will see the new version you talked about after this.

No, I'm okay. I think I've used it for such a long time that I'm so adjusted to it. In the beginning I had a lot of issues - if you gave me a paper then I would fill it with "I want this, I want that! Why do I have this? I can't believe it!"

But today it is so natural to me that I had to think about it before coming here, because I'll be meeting people that I want to talk about it with. And I think well, there are little things I want to change in the software. But I think that I have this because I've been using it for so long. People are always comparing it with propriety software, and I don't compare it anymore because it's been such a long time since I've opened something like Photoshop.

So, I'll think about it.

Jehan: But in the end it just works!_

Nara: Yeah. I've written some*, but not for GIMP, for Inkscape, Scribus…

[Editor's note: Jehan misheard the word "some" here as "song"]

Jehan: Ah! A song for everyone but us?

Nara: I used an earlier version of Inkscape which had a lot of bugs. They just changed it and so I have just bugs for Inkscape. Bugs are bugs.

Jehan: Ah, it's bugs, not a song!

Nara: Yes, for Inkscape. For Scribus, I have some issues with development.

Aryeom: So you have bugs for them, but you have requests for us. So it's good!

Jehan: Ah, okay. I thought you'd wrote a song.

Nara: No no - I know my letters are beautiful but it's not a song.

And I'm happy to meet you! Very happy. I don't go to a lot of events like here in Brazil. I don't have a lot of time to do that. And it's like an investment to travel here because it's very expensive and the country is too big, haha. So my involvement with free software is like in my community. On our street where we work, a lot of people use Linux because of us. It's like a center, you know? Time to time, someone goes there, "Oh, I bought a new notebook, I want to install Linux, let's do it together".

I think my part in this is more local than global - in the community. I feel better like this. Real connection, offline. I'm not so close to the development here and the other artists. And most of them, they're just show artists. They don't really work with design, they don't really live from this, you know? I tend to know people who live from free software. Most of them are professionals, who are really good at one software, but they don't put food on the table with it. It's a little different. I learn from them, but I want to know people who have real issues.

Because when you don't work with it, you just experiment, you make your own goals. Like "I'm going to make this girl have make-up on her face", and then you do that. When you work, another person puts a goal on you. Like, "Make this girl have a guitar", and you have to find a way to do that. And the process when you make a goal versus when another person makes a goal you have to achieve, it's very different when you're working with the software. Because you have to go somewhere you've never went before. And it makes you use the software in a different way.

You understand what I'm saying? Because when I see the workshops, people are very good at doing something they always do. I want to see people doing very good things they've never done before. These things show the real potential of the software.

Jehan: And the potential of the artist.

Nara: Yes, and the potential of the artist. Because you can show me, Inkscape or GIMP is doing this new thing. But maybe I'm not going to use it just because it's in the software. I'm only will use it if I need it. So, there are a lot of people who are experts in the tools and what the tools can do - to make it, you have to use all the tools combined. It's different, it's another level.

Jehan: Well, I think that's a good interview. Thank you Nara!

Nara: Thank you!

Estudio Gunga

09 Jul 2026 10:00pm GMT