After connecting some dots, it came to our notice that some conduct reports written through the conduct.gnome.org form might have been silently lost. If you have sent a report between Jan 5th 2026 and Sep 28th 2026 and got no response for it, we invite you to send it again, either through the form or conduct@gnome.org.

How

In Jan 5th, GNOME sysadmins introduced a filter to the CoC report form to prevent attempts of SQL injection. The filter was however overeager, filtering out messages containing certain natural English words that matched a subset of the SQL syntax. We do not know the full impact of this filter yet. After the issue came to our notice the GNOME sysadmins quickly fixed it on Sept 28th.

We appreciate GNOME sysadmins’ diligence and the speedy fix.

Contact us

If you’ve sent a message in this time period through the conduct.gnome.org form and are missing a response from the CoCC, we invite you to send the report again. It sounds likely that it was filtered down and missed by the CoCC.

The CoC Committee

I'm happy to announce the availability of a COPR repository which rebuilds Fedora 45 kernels with the patches from the qcom-laptops git branch added. This is a branch where various upstream pending patches with Snapdragon laptop improvements are gathered. For the exact contents of the latest kernel from this COPR see this Fedora kernel git-repo fork.

Installing the kernel from this COPR adds camera support for various X1 laptop models, adds bluetooth support for the ThinkPad T14s as well various other improvements. Most of these are expected to land in the 7.4 kernel.



comments

After the initial work to make Fedora live iso media boot OOTB on Snapdragon X1 laptops in Fedora 44, I've continued working on improving the Fedora experience on these laptops for Fedora 45. For Fedora 44 a long list of workarounds was necessary, see the Snapdragon laptop install instructions on the wiki.

For Fedora 45 various improvements have been made in the mainline kernel and I've been working on improvements at the initramfs generator / distro level. Together these result in a much smoother experience, see the install instructions for Fedora 45 on the wiki. A few workarounds are unfortunately still necessary for Fedora 45. For Fedora 46 I hope that the Fedora aarch64 live iso media will just work on X1 laptops.

Note that this blog post is about Snapdragon X1 (Elite,Plus) laptops. Support for Snapdragon X2 laptops at the same level as the current X1 laptop support is quickly coming together in the mainline kernel. But the 7.2 kernel used for the Fedora 45 beta and release isos is still missing some bits and Devicetrees, so Fedora 45 will not work OOTB on Snapdragon X2 laptops.



comments

Like many, I’ve been thinking a lot about the impact of LLMs on the free software community. In the GNOME community, there have been a couple of posts on Planet GNOME and Discourse, and assorted heated discussions on Matrix and Mastodon. We are not unique in this — there are similar conversations in the KDE and Debian communities as well.

I think we should be actively working on figuring out how best we can adapt to the new world we find ourselves in, and use LLMs for the good of GNOME.

The argument being made

Some folks in the community would like to have the GNOME project refuse to accept LLM-generated content (be it code, bug reports, or other forms of contributions).

The concerns are not unfounded. LLM-generated content can often be verbose, annoying to read, and downright incorrect. This is very dependent on specific models and how they’re used, and the state of the art is constantly changing.

There are other nuanced arguments around the subject, but I’m skipping them in the interest of brevity.

The thrust of the argument is the immediate increase in maintainer load, which is already a matter of concern in the project. I think this is valid, but I think we have to search for solutions to address this problem (for example, the Linux kernel project has Sashiko).

Inevitability

In my own experience, I have used LLMs to write new tools that I would not have had the time for. I have used them to learn about topics and codebases that would otherwise have taken me much longer to navigate. Using these tools, I have been able to solve some pretty non-trivial problems.

In the process, I am also learning the limits of the LLMs, what kind of usage makes sense in what kind of context, and how not to lose the process of critical reasoning while working with them.

In every conversation I have had with people across various parts of the software industry, the experiences are similar, and the process of software development is changing.

That means that we also have to change the ways in which we interact with each other in building the software that we care so deeply about. We do not need to eject our values to do that.

Access

Like me, other people are able to use LLMs to build prototypes, write patches, and as a learning tool. This is especially useful for areas where we don’t have good documentation. Sometimes the patches or the learning are wrong, but that is not terribly different from reading the code and learning as one often has to do. And as with any nascent tooling, we are still building the right mental models to use for the process.

This makes contributing to GNOME more accessible. The arcana of software development are suddenly not in the way of getting something done. Perhaps we could embrace the loss of those barriers and figure out how to include more contributors without adding additional burden to our maintainers.

Accessibility

There is so much we are yet to realise with LLMs. We could have LLMs (on-device, or otherwise) do:

• Live captions as hearing assistance
• Translations for non-native speakers
• Image descriptions as visual assistance

Some of this is table stakes now on other platforms. We have a history of continuous improvement to the desktop accessibility stack, and LLMs unlock a lot of new possibilities to raise the bar on what we are able to provide our users.

Keeping GNOME GNOME

There are a lot of details missing here — what would the processes look like, how do we keep the infrastructure free (open models? with open datasets?), and so on. But for that, we need to agree on a direction.

As a community, we have always been deeply invested in the human aspects of the software that we build. Even if the state of LLMs is frozen at the current level, we are seeing a sea-change in the process of building software, and we cannot hide from it.

As with other changes before this (the inception of the project, the adoption of the HIG, GNOME 3), it behooves us to play a positive role in defining how we build software for humans in the future.

Jordan Petridis evidently has strong opinions on the use of LLMs. He’s welcome to those.

What’s not welcome is when it escalates into vigilantism and defacement of bug reports. Specifically for me, this bug where a tag “Probabilistically Automated” was added. That tag has a meaning of

Usually accompanied by a lack of proper testing, and finalizing patches based on theoretical intended behavior rather than correctness of code.

I am reading that as screaming “It’s the work of the Devil!” in a shrill voice. The naming of the tag likewise suggests religious fanaticism.

The LLM work in the bug report was (1) specifically requested, (2) excellent quality, and (3) very helpful given that the underlying problem does not happen on my machine.

If you can’t be bothered to actually assess the quality instead of hiding behind “usually” then you are not adding anything positive and should stay away.

When asked for an explanation, none was provided. A comment on his blog post was, as far as I can tell, moderated away.

(I do agree that poor-quality LLM-generated bug reports exist. Do they ever. A tag like the above is not part of the solution to that, whatever it may be.)

Most modern operating systems (including iOS, Android, macOS, and ChromeOS) have been using image-based architectures for a while, and in recent years we’ve been making progress towards this on the desktop side as well. It’s a necessity if we want to provide the security, usability and reliability that people expect from their devices nowadays.

However, broadly speaking the adoption of image-based designs has been limited in the free desktop world so far because there are still a few major gaps. While Flatpak and Flathub have more or less solved the app distribution on these systems, the developer-facing story still looks much more incomplete.

Traditionally, people have been developing against the host OS they are running. Assuming you’re working on something like NetworkManager and need a new dependency, you’d just “apt install” it globally on your system, and then configure/compile against that. Similarly, if you need a command-line utility, compiler toolchain, or other build dependency, you’d also install them from the distribution repository.

In an image-based world this approach doesn’t work, and people have come up with various ways to address this.

RPM-Ostree and Package Overlays

Fedora Silverblue can be extended similar to package-based distros with rpm-ostree overlays, but the issue with this approach is that overlayed packages can completely break the system in unexpected ways or stop it from further updating. This is why the next iteration of Silverblue is based on “bootc”, and will be explicitly avoiding this paradigm. Same issue are present with other package overlay approaches as well.

Monolithic “Development” Overlay

The approach used by Android, iOS, Windows, et al is to have a single monolithic overlay with “system development tools”. Developers can install this overlay, and it provides all the utilities people developing the system itself need.

GNOME OS does something similar: There is a “developer” system extension that overlays the toolchain used for building the OS on top of the user-facing OS image. However, this is a finite list of utilities needed specifically to build the OS. As such, it can not cover the long tail of development and debugging tools developers in different areas need (e.g. kernel development).

Toolbox

Another approach is trying to replicate the same traditional package-based experience inside a container. Toolbox and distrobox are examples of this.

Unfortunately, with this approach you are still relying on the same old package infrastructure, while also being inside a more restrictive container environment that none of the tools expect to be run in. As such, you often run into limitations when developing system components and need to bypass the container layers in order to debug the system itself.

Homebrew

Homebrew provides an independent tool chain to develop against, but in order for homebrew binaries to be usable directly in the terminal, they have to be prioritized over system binaries. This means that the system can break if there is a mismatch between what the system expects and what homebrew provides. For example, you install QEMU, but it overrides the GLib your system uses for everything else.

There are other architectural issues with homebrew, but in my opinion this alone disqualifies it for system development.

Flatpak

Lastly, we have Flatpak. Like Toolbox it uses “containers”, so the same issues and limitations are also present here, but it’s even more restrictive because the assumption is that apps will use portals to access system resources such as directories and devices. Flatpak was designed specifically with desktop apps in mind, and its architecture and integration points are not well suited for command line apps.

Somewhat tangentially, there are apps that can’t be made to fully work with Flatpak as it is today, particularly debugging utilities and IDEs. While it’s technically possible (GNOME Builder and the Ptyxis terminal are proof), older applications were not designed with sandboxed resources in mind, or have not adapted to this model yet.

What Could We Do Instead?

While we would love for everything to be sandboxed and confined, that is sadly not yet possible. All the existing approaches that attempted to containerize tooling, run into the same conflicts between the desired functionality and the restrictions inherited by this approach. This is a topic we will discuss in more depth later on.

Additionally I believe there are two different use cases here. The build tooling/toolchain used by projects, and the developer utilities.

Project Build Setups

One aspect of this is the build setup used by individual project, which would ideally be something more deterministic, and containerized like Buildstream, flatpak-builder, bazel or even nix, instead of the old status quo “apt install -yqq gcc meson libone-devel libtwo-devel”. This is also a topic for another day though.

Developer Utilities

The other aspect, and what I want to focus on today, is that a lot of developer utilities that people rely on can’t realistically be run in a confined environment (such as a container) without a near complete rewrite.

We need a way to make things like strace, ripgrep, and qemu available. Shipping them in the host system is one option, but there is a real long tail issue here. You can’t (and don’t want to) provide every single utility any developer might need. Thus we need them to be shipped independently, and as such, not attached to the host OS.

Toolpak

If we were to take a fresh look at this issue and design something from scratch, what would we want it to look like? Over the past months we’ve had a number of discussions on these topics, and it feels like we’re finally converging on a solution would address most people’s concerns and needs.

These are the important properties we would want:

• Tools should be independent from the host OS, and they should not break the host OS if something goes wrong. They need to be able to access every resource in the system, much like today.
• A large catalog of existing tooling, like we find today in distribution repositories today.
• Tools work out of the box, and will be fully functional, as it’s not feasible to modify all of them. Things like shelling out to other tools should work like it does now.

Here is what I imagine an implementation, which we will call Toolpak, would look like:

• Discoverable Disk Images (UAPI.3) as the image format. This will provide us state of the art security practices, like Verity. It will also give us a good base for allowing Reproducible builds, given that the build tooling permits.
• A mount namespace for the binaries. The /usr and /app split from Flatpak is a great idea and we should also steal it much like portable services now can use Base/Runtime images! /usr should be provided by the “Runtime Image” and shared among tools. And /app will be the main contents of the Tool image.
• Tools have unrestricted access to everything else. This should also satisfy the “no need to port” requirement (Some edge cases where the mount namespace will conflict, but they are minor).
• We should prepend the tools, to the PATH of the user (ie. our binaries will override the system ones), but it should avoid breaking the system as you can only override the system binaries. Said binary will then setup the mount namespace and execute the real binary from inside the image. This avoids messing with the linker and shared libraries. Unless you overriding the system GNU Tar with the BSD Tar (or other incompatible cases of the same binary), things should work fine. More research is needed to explore what other safeguards will be required.
• Tools can not depend on other tools. One of the issues with traditional distributions is dependency resolution and package management (this is subcategory of a heavily discussed topic, I also talked about it in my LAS talk from 2025. We should avoid making individual packages or having dependencies between tools, to avoid all the unnecessary complexity that comes with it.
• Tools will bundle all their dependencies. This will ensure that they will always execute against the environment they were tested against. It additionally allows tools to bring their own versions of libraries that might be present in the system, without conflicts. We mentioned the /usr and /app split above.
• Great user experience to discover and install tools. There should be a flagship “app store” and ideally the tools should be packaged and distributed by the developers themselves, similar to Flathub. No more “download this static binary and chmod +x it”.
• Tools have complete and arbitrary access to the system, so it’s crucial that it not be simple to install random images. They will be have to be signed with a trusted key, and verity checked at runtime, and be thoroughly reviewed before appearing on the flagship “app store”, and all the other practices we should expect from distributing software securely.
• Apps that can be packaged using Flatpak should be rejected. Unless they are less functional, like IDEs on Flathub.

In order to be adopted, it will also have to come with tooling that will make it easy to build said Toolpaks. Here are some specific properties the build tooling should have:

• It should be easy to orchestrate builds of your tool and its dependencies.
• Great caching for all build artifacts in a Content Addressable Storage.
• Reproducible by default, with tooling to easily verify the output.
• Can be used for both local development and composing the final image.
• Handles all the licensing/SBOM/etc requirements.
• A Buildstream plugin or wrapper around it should satisfy all these needs.

Next Steps

While this topic has been discussed for years, there’s now concrete work towards a prototype as part of a Prototypefund project. We plan to share more on this in the coming weeks and are interested in feedback from the wider community. In the mean time, if you have any other feedback, find us in #gnome-os:gnome.org on Matrix, or leave a comment.

Update on what happened across the GNOME project in the week from September 18 to September 25.

Third Party Projects

Titouan Real announces

Era is a new calendar app for mobile and desktop that grows with your needs. It’s simple and calm for everyday use, while powerful features remain available when you need them. Use Era in a small window alongside other apps for multitasking, or switch to fullscreen for complex planning. It syncs your events with most online providers and continues working when you’re offline.

This week Era’s first beta version was released on Flathub, following more than a year of development. Download Era from Flathub now and report any bugs you can find.

For those interested in the technical details, Era is written in Rust and built with libadwaita for the GNOME desktop. We’re also working towards Android support and an APK is available from the CI pipeline. Under the hood, Era uses an extensible, modular calendar backend. It currently integrates with Evolution Data Server, while an experimental peer-to-peer backend based on p2panda is also available in devel builds.

Contributions are welcome, whether through code, testing, translations, or design. Check out the repository and join the conversation on our Matrix channel: https://matrix.to/#/%23era:gnome.org to get involved.

Particular thanks go to Philipp Sauberzweig for working on the design, as well as to everyone that helped me across the GTK, Libadwaita, Rust ❤️ GNOME and other communities!

Tanay announces

Deep Dive - Submerge into Deep Focus

This week I launched Deep Dive my second app after Whisp, Deep Dive is an active productivity timer built for the GNOME desktop. Based on the concept of “Submerging,” it operates on the principle that deep work requires strict boundaries. When you start a timer, you go underwater where distractions cannot reach you—you either finish the dive, or you deliberately “Give Up” and surface early.

You can choose between a Pomodoro Session or a Timer Session but that is not it -

Other Features Include :

• Submerge Mode: Locks the timer, completely preventing you from pausing or skipping your focus session.

• Break Overlays: Forces you to step away with a full-screen overlay during your scheduled screen breaks.

• Do Not Disturb Integration: Automatically silences system notifications while you are submerged in a work block.

• Project Tracking: Securely logs your focused time against specific projects locally on your device with graph based Stats

• User Customizability: All of this is customizable from length of the Pomodoro to Break Limits even Notifications

Deep Dive is now officially available on Flathub:

Website: https://tanaybhomia.github.io/DeepDive/ Flathub: https://flathub.org/en/apps/io.github.tanaybhomia.DeepDive Repository: https://github.com/tanaybhomia/DeepDive Support me : https://tanaybhomia.github.io/donate.html

Feedback is always welcome.

Capypara says

This week I updated Field Monitor. Field Monitor is a remote desktop client designed for GNOME that is optimized for connecting to virtual machines. It’s now more stable and performant than before and it’s UI has been simplified. It now also supports direct QEMU/D-Bus connections for configured KVM/QEMU libvirt VMs.

Download on Flathub: https://flathub.org/apps/de.capypara.FieldMonitor

Will Warner announces

Quadrapassel 51.0 has been released!

Here’s what is new:

• Added the Cornish translation
• Updated translations: Lithuanian, Russian, Belarusian, Czech, Ukrainian, Georgian, Chinese (China), Slovenian, Swedish, Brazilian Portuguese, Kazakh, Hungarian
• Fixed a bug where blocks would not stop moving if the game lost focus
• Fixed a bug where game keys wouldn’t work once if they were pressed before to starting a game
• Added a -1 difficulty, where the level never increases
• Modernized the ‘Game Over’ view
• Modernized the game themes and removed the tango and tango flat styles
• Changed the game stats to use cards
• Replaced the ‘Appearance’ dialog with an ‘Appearance’ page in the preferences

You can get Quadrapassel on Flathub.

Will Warner also announces

Solitaire 51.0 is out!

Here’s what is new:

• Added the Polish and Finnish translations
• Updated translations: Slovenian, Ukrainian, Chinese (China), Georgian, Kazakh, Brazilian Portuguese, Swedish, Cornish, Georgian
• Made target card stacks dim
• Made cards show different cursors
• Fixed bug where redoing a move would not run the solver
• Changed the game save feature to allow up to 4 saves at a time
• Improved focus, dragging, and selection indication
• Moved the appearance selector to the preferences, and improved its layout
• Made the new game button save the current game and always move to the game selection
• Moved unfinished games to a new section
• Moved the undo and redo buttons to the menu
• Changed the window color to have better contrast
• Fixed a crash when the waste was clicked while empty in the Pyramid game
• Changed the pyramid game rules to only require the pyramid to be empty for a win

You can get Solitaire on Flathub

Rat Cornu says

ratic music player had small improvements the past weeks with the new releases 0.4.2 and 0.4.3! The musics in the queue can now be reordered, and a small menu button is next to them to perform some actions, like going to the music album, or showing a dialog with the music tags. A right click on a music on the main view also open the same menu. Moreover, a noticeable change in the settings occurred, making clearer what picking a music does. Other small things has been fixed. You can check the new versions on flathub, on the repo, or even come discuss with us on our matrix room! Thanks again for all the people that contribute to the localization on weblate!

ckappgit says

AkiZip, our GTK4 archive front-end manager written in Python, has been updated to 0.4.0 on Flathub!

You can now process multiple files at once instead of being restricted to single-file operations.

A core maintainer has also returned to active development to help move the project forward.

Additionally, the security vulnerability fixed back in version 0.3.4 (GHSA-pxfq-f5pr-6crv) has now been officially assigned CVE-2026-92699.

Update AkiZip on Flathub and check out the repository!

Links: GitHub: https://github.com/AkiZip/AkiZip Flathub: https://flathub.org/en/apps/top.akizip.akizip

Alexey Volkov announces

Tailor - Create Bootable Drives

A tailor stitches - this one stitches OS images onto your flash drive

Recently launched Tailor - application for bootable USB creation without hunting .iso on internet.

Tailor has own OS catalog, using osinfo-db base. Pick OS family, edition, version, arch, then click ‘Create Bootable USB’. Image downloads (stays cached for rewrite later), Tailor checks checksums and starts writing.

GTK/Adwaita does not mean that Tailor is Linux-only: it is available on Windows too!

Tailor is now officially available on Flathub:

Repository: https://altlinux.space/qualimock/Tailor Flathub: https://flathub.org/apps/org.altlinux.Tailor Windows builds: https://altlinux.space/qualimock/Tailor/releases

Feedback is always welcome.

Lanséria says

New week, new update! Hello everyone, this week I’ve updated PedantiK to version 1.7.0, with two features : hints and list of previously guessed words.

You can now reveal random words in the page to help you if you get stuck, and all your guesses will be shown in a sidebar, allowing you to review what you’ve already guessed!

Thank for the community to suggesting these ideas! And have fun :D

xjuan reports

Casilda 1.6 Released!

A simple Wayland compositor widget for GTK 4

This release includes Clipboard and Drag&Drop integration with the host compositor.

You can read more about it at blogs.gnome.org/xjuan/2026/09/24/casilda-1-6-released/

Release Notes:

• Add DnD and clipboard support
• Add support xdg_foreign protocol
• Fix modifiers in pointer button press events
• Add keyboard Caps/Num/Scroll Lock support
• Fix popup of popup crash
• Fix maximized/fullscreen state handling
• Fix modifiers flags creation (Evgenii Danilin)
• Drop cursor surface listeners when the surface is destroyed (Evgenii Danilin)
• Close dup’d plane FDs when a dmabuf import fails (Evgenii Danilin)
• Advertise a valid output scale to avoid a scale-0 assert (Evgenii Danilin)
• Unref the wayland GSource (Evgenii Danilin)
• Meson config cleanup (Val Packett)
• Use gtk api for snapping to device pixel grid

Давид Султаниязов says

ReadySet 0.13.1

The modular application for installing and initializing the ReadySet system was already mentioned in TWIG #233, and we’re back to tell you what we’ve done in the meantime.

New plugins

ReadySet has started to acquire built‑in plugins for convenient use in various distributions:

• date-and-time — selecting the date, time, and time zone, including auto-selection by language;
• software — adding ThirdParty repositories: Flathub, proprietary solutions, and so on;
• network — configuring Wi‑Fi and the computer’s name on the network;
• privacy — privacy settings. For now, this only includes enabling automatic geolocation detection;
• license-agreement — accepting the license agreement.

ReadySet is already in use!

Now ReadySet is used in some systems of the ALT Linux family — ALT Mobile (a system for mobile devices), ALT Regular Gnome (a regularly updated image), and ALT Atomic Onyx (an atomic distribution with GNOME).

Currently, it is used as a master for initial setup for these systems, and later it is planned to use it as an installer for ALT Atomic systems — the development of the plugin has already begun.

Adaptive interface

The main improvement to the interface was the enhancement of adaptability. ReadySet can operate in three modes depending on the screen size and format:

• for tablets and portable set‑top boxes — a horizontally elongated small screen;
• for mobile devices — a vertically elongated small screen;
• for computers — a large screen.

Some widgets have been moved to the libcase library, which other projects will be able to reuse.

Architectural changes

ReadySet now supports various operating modes:

• installer — a mode for use as an installer;
• initial-setup — a mode for the initial setup wizard;
• existing-user — a mode for additional configuration during updates and the introduction of new functionality.

Special attention has also been paid to integration with GDM for running in kiosk mode and seamless transition into the system immediately after the initial setup is completed, without the need to re‑log in as the user.

For developers

For testing in CI/CD, images are built based on ALT Atomic Minimal with GNOME and Phosh, with ReadySet added; these can then be installed on a virtual machine to test functionality.

In the future, it is planned to create a knowledge base so that other distribution developers can integrate ReadySet into their ecosystem.

dabrain34 reports

🎉 New Release Announcement: GstPipelineStudio v0.6.0 🎉

It’s a great pleasure to announce the release of GstPipelineStudio version 0.6.0! This release adds an auto-suggest engine that proposes the next element to connect to your pipeline, brings GstPipelineStudio to three languages and moves the interface to libadwaita.

Highlights:

• Auto-suggest engine proposing the next element to add
• Caps typing with typefind and demuxer caps discovery
• Open Media URI dialog for uri-property elements
• Pipelines list view and multi-node rubber-band selection
• Read-only graph mode during playback
• Translations for French, Spanish
• Reworked UI with libadwaita dialogs and GraphView themes
• Category badges and media-type colors on elements
• GStreamer 1.28.7, GTK 4.22.4 and libadwaita 1.9.2
• HTTPS support bundled on Windows and macOS
• Rework the GStreamer log handler

Participants:

• Stéphane Cerveau — maintainer and main contributor
• Dillon Hemphill
• Translations contributed through Weblate

🚀 Upgrade Now!

To get the latest version of GstPipelineStudio, visit the project’s page and check out the Changelog for more details.

Happy streaming! 🎬📡

Bilal Elmoussaoui reports

I have released a new beta version of oo7 crates in preparation of it adoption in the wider linux distribution communities. You can find more details at https://github.com/linux-credentials/oo7/releases/tag/0.7.0.beta

Shell Extensions

swink announces

Now Playing Card puts a little equalizer in your top panel. Click it for cover art, seeking and controls. It works with any player: Spotify, browsers, whatever. Install it and forget about it. It took about a month from first commit to store. The idea took an evening. The rest went to cover art, because every player sends it differently.

Get it: https://extensions.gnome.org/extension/10736/now-playing-card/ Source: https://github.com/epogonii/nowplaying-card

swink says

Wisp, a GNOME Shell extension that brings snapper into the top bar.

On most btrfs systems snapper keeps taking snapshots in the background, yet restoring from one usually means dropping to the terminal. With Wisp you can list your snapshots, check what changed since any of them, pull back individual files, or roll the entire system back, all from the panel.

Get it: https://extensions.gnome.org/extension/10755/wisp/ Source: https://github.com/epogonii/wisp

somepaulo says

The Weather Or Not extension has been updated for GNOME 51. The code has been almost completely rewritten to use underlying functionality already available in Shell instead of recreating them. Generally, the extension now works much more clearly than before.

On the user facing side of things, there’s now a smooth transition when weather data changes and a spinner for when data is first loaded on boot, on location change or after a long time without a connection. Stale weather data gets dimmed after an hour with no successful updates.

Last but not least, accessibility has been improved with proper support for detecting keyboard presses and for the reduced motion setting.

The new version has already been approved and is live on EGO..

Miscellaneous

Hari Rana | TheEvilSkeleton (any/all) 🇮🇳 🏳️‍⚧️ reports

The “3. Probabilistically Automated” label has been appointed throughout the GNOME/ namespace on GNOME GitLab, for labeling tickets/issues and merge requests that use artificial “intelligence”. This new label describes itself as the following:

Major or total reliance on “AI” / LLMs / stochastic parrots to generate code or bug reports. Usually accompanied by a lack of proper testing, and writing reports or finalizing patches based on plausibly sounding intended behavior rather than correctness of code.

We decided to use “probabilistically automated” as the label to avoid anthropomorphizing artificial “intelligence”.

The discussion took place in the Calendar Matrix room, with contributors from different projects (specifically, Document Scanner and Nautilus). Calendar already used the “Probabilistically Automated” label but only internally, which was also announced on GNOME Discourse. Document Scanner was the second one to use the label in the project by recreating the label, and one of the Nautilus developers was looking into recreating the label for Nautilus. Since this was a lot of duplicated effort, we decided to appoint it throughout the GNOME/ namespace, so every project that bans AI contributions can also use this label. The only thing that needed to be done was to tweak the wording and then appoint it.

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!

GNOME and KDE have started to consider LLM policies, and we should talk about what this is really about.

KDE caught everyone's attention first by igniting a flame war with an LLM-friendly draft that ended up being deleted, causing a few bans, and having a bunch of people go full "Some of you may die, but that is a sacrifice I am willing to make". GNOME has not proposed anything official, but some teams (gnome-calendar, loupe, libadwaita, gnome-software, Circle, among others) already have strong policies in place, and there is now an informal draft to ban all LLM contributions to GNOME projects and infrastructure.

However I believe these discussions are not about nitpicking workflows but rather about the raison d'être, the reason to be, of FLOSS projects.

Communities Or Completionism

My take is that there are currently two ways of thinking about why FLOSS exists, or should exist. So far, both sides have coexisted but the growing acceptance of LLMs into some developer workflows has disrupted the balance.

We can call one of these sides "collectivism". This frames FLOSS to be about accomplishing things together, enjoying the journey and bonds that big goals tend to create. The fun is the collective effort and challenge. Overcoming language and social barriers is part of the reward. "The journey is the destination", "FLOSS is the friends we made along the way", etc.

On the other side there is "completionism", where FLOSS is "just a product" and its only goal is to always be better, faster, safer. Any fun to be had is in individually solving technical problems and requirements. Social bonds may happen, but colleagues are more coworkers than community. This is a "100% allglitches alltricks" TAS speedrun. The "we are apolitical", "we only care about the code" view.

My assessment is that the collectivist framing finds FLOSS primarily a social exercise that rewards you with experiences, bonds, and ideas outside of your niche interests. Some times you even get good software as a bonus! The second framing sees FLOSS as a tool to scale the complexity of your individual computer interest, like graphics or security. FLOSS is a convenience compared to manually rebasing patches and forks all the time.

The problem we are facing is that LLMs have given the second group a lever to stop giving the collectivist framing any room. When the LLM can get you 80% of the way to your goal, there is no need to "waste" time in mentoring, discussion, or convincing others. The temptation compounds if you are considered an expert in your field. You can surely fill in the last 20%, right? Is anyone going to challenge not only the machine, but also the expert?

Progress At All Costs

Since LLMs present themselves as neutral, and dispassionate, opposition to their output becomes opposition to objective progress: bug fixes, security hypotheticals, features. Progress is whatever the LLM, under my own careful eyes, says it is. Interactions with others become formalities, since the LLM is simply boosting my own, already expert and close to infallible, output. Right?

Unfortunately this "expert slop", where expert is a self-perceived title, carries a corporate framing that damages interactions. Others become, at best, fungible coworkers, and, at worst, annoying speed bumps in the race to 100% completion of any software interest the expert has. No more mentoring, debating, flame wars. "Progress" is the only goal. The line must go up.

There is more to say about how this machiavellian framing causes far more important harms and externalities, in the name of LLMs themselves, or apparent LLM-assisted progress. Think of any group and you will find out they have been handed part of the bill for these externalities:

• The people who will lose their homes, schools, lives, in the Global South because of El Niño 2027
• The towns destroyed by data center illegal and irresponsible practices
• The price of all consumer goods going through the roof because of financial speculation
• The pensioners who might lose their pension when the bubble finally pops.

These are the real costs in the "Progress At All Costs" that LLMs bring into FLOSS. These are the people who will pay the bill, behind the scenes and far from our screens, so that some big brain engineers can avoid reading documentation, writing boilerplate, learning unfamiliar code, or, worse, working with others.

FLOSS As Principled Software

Almost ten years ago Allan Day described GNOME as Principled Software because of its commitment to always doing the right thing, in code or design, because it was the right thing and not because of ease, pressure, or hype. I believe this is why so many other FLOSS projects have always looked at GNOME for guidance on what good FLOSS should be. This discussion is just another opportunity to continue to meet this expectation.

Recent discussions have shared similar sentiments like reminding us that we do book clubs because we want to read and enjoy books, not to just discuss over summaries because it is "more productive". That when pressed to accelerate FLOSS, to make the line go up, we have to ask for whom do we want to be more productive, efficient, faster?. And that every decision is political and affect other people around you.

We already know that LLM productivity is not real, just a self perception, that LLMs are just a fairy tale to maintain tech stocks hypergrowth, by farming engineers for engagement, and the latest in a series of attacks to commoditize tech workers. Knowing all this, are we still going to play along with big tech's lies and exploitation? Or, are we going to make another principled stand?

GNOME did not need LLMs to produce 30 years of creative engineering, design, localization, inclusion, and collaboration that has been shared with people around the world. It does not need to throw away this incredible legacy simply because LLMs happen to farm our worst individualist impulses.

We came this far without compromising our principles, let's not start now.

DnD Release

I am very happy to announce a new version of Casilda!

A simple Wayland compositor widget for Gtk 4 originally created for Cambalache

This new version brings Drag&Drop and clipboard support / integration with the host compositor which means you can drag something from a host application and drop it on an application window embedded in a Casilda compositor widget and vice versa!

After a very rugged GUADEC presentation where I tried to show how to create simple Gtk application from slides made with Cambalache using a Casilda compositor to embed GNOME Builder and Cambalache itself I decided to fix all the issues I found so I could redo the presentation and upload it as a video.

This is a screenshot of the slider window, inside it there is a Casilda compositor (green line) used to embed a Cambalache instance which uses another CasildaCompositor (red line) to preview the UI.

Things that possi-bly could go wrong and did:

• Clipboard (Could not copy paste snippets)
• Keyboard numeric pad
• Keyboard modifiers in pointer events (I could not use Alt+Click to force create widgets)
• Example application connected to host compositor instead of Casilda widget
• Gnome Builder fullscreen window state broken
• Popover tooltips crash

After fixing all the bugs and keyboard support I started working on adding Clipboard integration with the host.

Clipboard support

Integrating the clipboard between Casilda and Gtk was fairly easy since all I needs to be done is copy all the clipboard data provided by wlroots wlr_seat::request_set_selection event to GdkClipboard and call wlr_seat_set_selection() on GdkClipboard changed signal.

Wlroots client to Gtk

In other to do this I created a new GdkContentProvider that uses a wlr_data_source as the source of the data and set the provider as the content of the clipboard with gdk_clipboard_set_content().

Internally when a clients wants to get data from the clipboard the new provider creates a unix pipe to read data from wlroots by writing to the pipe with wlr_data_source_send() and reading form the other end using g_output_stream_splice_async().

 Gtk to wlroots to client

To go in the other direction I created a new wlr_data_source that uses a GdkClipboard as source and set selection with wlr_seat_set_selection()

Internally gdk_clipboard_read_async() is called to initiate the data read when wlr_data_source send() method is invoked to send the data to the client.

 Drag & Drop support

Integrating D&D was not as easy as the clipboard. Setting it up to work within Casilda is easy enough other than wiring up some events all I had to do was draw the drag icon surface.

The first thing I did after getting the drag surface was draw it at the pointer coordinates which produced blurry results since pointer coordinates are fractional which means they do not always align with the pixel grid.

That was all nice and good but now I needed to start integrating the drag with Gtk (host compositor) so right after calling wlr_seat_start_pointer_drag() I created a GdkDrag with gdk_drag_begin() and used gtk_drag_icon_set_from_paintable() to set the drag icon and I noticed it was still blurry!!!

After a minute of confusion I realized that Gnome Shell (mutter) must be making the same mistake I did before so I decided to see if I could fix it!

Thanks to Michel Dänzer for guiding me and reviewing my MR, Gnome Shell 51 should have sharp drag icons!

Now back to integrating DnD with the host compositor.

These are all the different use cases that are needed to make D&D work transparently across host and guest compositors:

• Casilda client to Casilda client
• Casilda client to Host client
• Host client to Casilda client

Of course wlroots only contemplates the first use case, the other two cases are specific to Casilda.

Casilda to Host

So far we can detect when a client start a drag, let wlroot handle it and create a GdkDrag to let Gtk initiate another drag at the host level.

This means that when a client embedded in a CasildaCompositor initiates a drag there are two simultaneous drags at the same time, in the guest and host compositors. Keep in mind Casilda always delegates drag icon rendering to the host compositor.

During normal operation Casilda gets events from an event controller, but while on a drag operation events are not sent to the client at least not in the normal way, for that you can use a GtkDropTargetAsync and connect to the various signals for example I use drag-motion to forward events to the client.

Host to Casilda

When a Drag is initiated in the host compositor Casilda reuses the GtkDropTargetAsync created to track motion events and connects to drag-enter signal to create a proxy drag source in wlroots and synthesize a button release event on GtkDropTargetAsync::drop to trigger the drop on the guest side.

Here is a screencast off all the different use cases in action.

As you can imagine getting all this to work together correctly is not trivial and I expect to be subtle bugs in different corner cases so please if you find one of those file a bug and include a screencast if possible.

Release Notes

• Add DnD and clipboard support
• Add support xdg_foreign protocol
• Fix modifiers in pointer button press events
• Add keyboard Caps/Num/Scroll Lock support
• Fix popup of popup crash
• Fix maximized/fullscreen state handling
• Fix modifiers flags creation (Evgenii Danilin)
• Drop cursor surface listeners when the surface is destroyed (Evgenii Danilin)
• Close dup’d plane FDs when a dmabuf import fails (Evgenii Danilin)
• Advertise a valid output scale to avoid a scale-0 assert (Evgenii Danilin)
• Unref the wayland GSource (Evgenii Danilin)
• Meson config cleanup (Val Packett)
• Use gtk api for snapping to device pixel grid

Fixed Issues

• #20 “SIGSEGV in server_request_acvtivate”

Where to get it?

Source code lives on GNOME gitlab here

git clone https://gitlab.gnome.org/jpu/casilda.git

Matrix channel

Have any question? come chat with us at #cambalache:gnome.org

Mastodon

Follow me in Mastodon @xjuan to get news related to Casilda and Cambalache development.

Happy coding!