• Pl chevron_right

      Hylke Bons: Icon for Ripples

      news.movim.eu / PlanetGnome • 0:00

    Icon for Ripples

    Week 33

    This week's icon is for Tau Gärtli's project:
    Ripples: "Rip CDs"

    Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

    Need icons?

    I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

    • Pl chevron_right

      This Week in GNOME: #269 Permission Admission

      news.movim.eu / PlanetGnome • 3 days ago • 6 minutes

    Update on what happened across the GNOME project in the week from October 2 to October 9.

    GNOME Circle Apps and Libraries

    Brage Fuglseth reports

    This week Concessio was accepted into GNOME Circle. Concessio helps you understand and convert between unix permissions representations. Congratulations!

    2f1849ed8a0d704334ebf87e00eff855d8fbd5bb2107161291905826816_io.github.ronniedroid.concessio.DCawWEf8_Z2haIkP.webp

    Ronnie Nissan reports

    This week I released Concessio version 1.0.0. I am very proud that it got accepted into GNOME circle as announced above, it also got the following improvements.

    • A full rewrite from Gjs to Vala, making Concessio very fast, the code base clean and easier to contribute to.
    • Redesigned the file opening workflow
    • Added drag and drop support for opening files
    • Added support for changing file permissions, with the ability to undo changes
    • Improved the umask calculator to calculate from umask, file, or directory permissions
    • Improved accessibility throughout the app
    • Improved input validation and editing behavior
    • Updated translations

    I am also working on writing libacl binding for vala so I can add ACLs support to Concessio later on, if you have experience with writing bindings and this project interests you, please reach out. Thanks!

    ad1de26dba089f4ac4092ec42ed2cdb05305a1572107709355943002112_concessio-v1.0.0-help-page.Dadh0Uvx_1cuE2r.webp

    a160f9633f5bc124620a21beea4e02a2e5256bd82107709360569319424_concessio-v1.0.0-umask-page.DBFDVOXw_ZMVLoO.webp

    cbe31305e89d28b4b21a7e2cb8bd647155ddf4c72107709353384476672_concessio-v1.0.0-editing-file-permissions.CuuxKbsc_Z2kjj9l.webp

    853b64d619b618af847cb0e92987989edcc29d8c2107709357784301568_concessio-v1.0.0-main-page.BcxjvTBC_ZAY4kI.webp

    Third Party Projects

    Ronnie Nissan says

    This week I also updated my other apps, Sitra and Embellish.

    They both got the latest GNOME runtime 51, Embellish also was also updated to NerdFonts v3.5.1 which adds the messing Devicons that were promised in v3.5.0.

    I would also like to announce that I am looking for a maintainer for Sitra, if anyone is interested in a Vala GTK4+Libadwaita program, please reach out, if I find you are willing to take care of the project, I will hand it over completely.

    Tanay announces

    Whisp V1.6.0 -Runtime Update and Fixes

    New Features

    • Note Statistics (::count): Type ::count anywhere in your note to instantly inspect word, character, and line count statistics.
    • Asterisk Lists: Create and format bulleted lists using standard asterisks (*) alongside dash lists.
    • Shortcut Recorder Improvements: Pressing Backspace inside the shortcut recorder now cleanly clears or disables assigned shortcuts.

    Fixes & Maintenance

    • List Toggling Refactor: Fixed Ctrl+S list item toggling to prevent multi-checkbox stacking and unintended line deletions.
    • GNOME 51 Runtime: Updated Flatpak runtime to GNOME 51.
    • Slate Mode Polish: Fixed update notification banner layout in Slate Mode.
    • Compose Key Fix: Corrected key press handling for Compose Key combinations.
    • Ubuntu Icon & D-Bus Fixes: Fixed missing application icon issues on Ubuntu desktop sessions.

    Links : Download | Github | Website | Donate

    Whisp Development is made possible by users like you, If Whisp brings you value do consider donating.

    dhUOwgetNvXlvlDlEMospLCF_image.DTtXQB5Q_1dYmB5.webp

    tfuxu announces

    Flood It 3.0 released, finally bringing resizable game boards and toggable number indicators on colors.

    Check it out on Flathub!

    LvuDyCyeSWksXLJNEFZLwuVn_screenshot-5.B1QWewTF_ZEkUm3.webp

    vmnAVJHNRLDXjaVDjgFFAdwI_screenshot-6.DOwPG2fi_Z1y5wKc.webp

    Titouan Real reports

    Era 0.2.0 is out. Download Era from Flathub now and report any bugs you can find.

    Era is a calendar app for mobile and desktop, designed to stay simple for everyday use while offering powerful tools when you need them. It syncs with most online calendar providers and works offline, too.

    What’s new:

    • Move events with drag and drop within the month view, or drag an event into another app to export or share it as an ICS file.
    • Import external calendar events with high-performance parsing.
    • If Era 0.1.0 felt slow, give 0.2.0 a spin! Major performance optimizations are live in this release, with even more speedups currently in development.

    Era is also available on GNOME Nightly for the latest features, bug fixes, and performance improvements.

    Anton Isaiev announces

    RustConn is a connection manager for SSH, RDP, VNC, SPICE, Telnet, Serial, Kubernetes, Web, and Zero Trust, built with GTK4 and Libadwaita.

    Version 0.23 is out, bringing major interface updates, workflow enhancements, and security hardening since 0.22:

    User Interface & Experience:

    • Rebuilt the main window layout around the GNOME HIG with separate sidebar and content pane header bars (matching Files and Settings).
    • Protocol filters are now neatly folded behind a single Filter button.
    • True fullscreen mode now hides both the header bar and tab bar for an unobstructed session view.
    • Added keyboard passthrough to hand desktop shortcuts (such as Super and Alt+Tab) directly to embedded RDP and VNC sessions.

    Connection & Session Management:

    • Keystrokes can now be broadcast across groups of tabs, not just individual split panes.
    • Any pane within a split can now be reconnected in place independently.
    • External FreeRDP and VNC viewers can now be pinned on a per-connection basis.
    • Zero Trust sessions with expired cloud logins now provide a one-click re-authentication flow (AWS, Google Cloud, Azure) directly within the tab.
    • Added per-connection command macros triggered by keyboard shortcuts.
    • Clusters can now automatically collect members matching a regular expression.
    • Context menus now feature a dynamic Copy submenu showing only existing connection details, alongside an Edit Connection action.

    Credentials & Protocols:

    • Added a read-only mode and search-from-root toggle for secret backends (Bitwarden, 1Password, Passbolt, pass, KeePass), allowing vault discovery without granting write access.
    • Added support for KeePass databases protected by YubiKey Challenge-Response slots, complete with interactive “touch your key” prompts.
    • Connection editor can now auto-detect a host’s MAC address for Wake-on-LAN in one click.
    • Added opt-in H.264 support for RDP via Cisco OpenH264.
    • Added a dedicated KDC address field for Kerberos authentication on realmd/sssd environments.

    Security Hardening:

    • Multi-line terminal pastes now require confirmation via an interactive preview, preventing pastejacking attacks.
    • Added route-change warnings: RustConn alerts before sending stored credentials if a connection’s host, port, account, or jump host changed since the last run.
    • Hardened embedded RDP file downloads against hidden dotfiles (e.g., .bash_profile) and bidirectional-override character exploits in filenames.
    • Centralized argument sanitization for FreeRDP launches to drop unauthorized parameters (e.g., /shell:, /proxy:) from imported profiles.

    Plus numerous stability improvements and bug fixes.

    Thanks to everyone who uses RustConn, reports bugs, contributes or supports the project - this cycle was driven largely by issues people filed. If you’d like to support development, the repo has a Sponsor link.

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

    uHfnWxSZPlpmUNmOMhdNBMME_split_view_dark.Al1x73cC_29Q61Q.webp

    yMuHFVoVhBDCJllTPVJZpylP_welcome_dark.BeR2-OIp_Z1YMPne.webp

    oWuSEzGJaAxzkQLvHaHozhej_tab_overview_dark.BEeXeBKi_Z2w39U.webp

    Rat Cornu announces

    Ratic got a new version 0.4.4 this week, with two big changes!

    First, the dynamic background (based on the current music cover image) does not mess with colors anymore. It is much cleaner and consistent thanks to the color thief algorithm.

    Second, lyrics are now supported in ratic, both synced and unsynced! For synced lyrics, the current line is highlighted to follow your song, and you can click on the line you want to jump on to seek this particular position in the music.

    You can check the new version 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! I never imagined that so many languages would be added to a small project like mine.

    Cru4GLvEdoo9Su2yOJu5QSB54KEBT1FL_image.DFwYsRun_Z2lxJap.webp

    Z5TcQtAUdnJpAMtK2MnsZ5RarknPr9cd_image.DRIE5lJ8_14Lslm.webp

    Shell Extensions

    swink announces

    Now Playing Card got several updates.

    It adds an animated indicator to the top bar with a compact media card for any MPRIS player: cover art, a seekable progress bar and transport controls.

    Recent updates (1.0.4–1.0.8) bring:

    • a spectrum analyzer that moves with the sound itself
    • a redesigned popup: one surface, rounded cover art, slimmer controls, and separate tiles when several players are running
    • covers given as web addresses (e.g. Spotify) now load without an empty square while they download
    • a right-click menu on the panel button to choose visibility and open settings
    • click the speaker to mute, click again to restore the volume
    • the card follows the shell theme’s text colour, so light themes on a dark system (and the reverse) look right

    Source code is on GitHub.

    OvCFgEJuwUQJpqcXXBRabsjP_card.Byzj8KH0_Z2k55dt.webp

    URfbjDVokxXpYMMAOZHgnzyb_spectrum-dark.DbpQ9iqj_j8tvP.webp

    GNOME Fellowship

    Peter Eisenmann says

    I posted my monthly GNOME Fellowship update for the “slow” month of September 🐢 https://blogs.gnome.org/p3732/fellowship-report-september-2026-moria/

    Sophie (she/her) announces

    CMYK support in glycin and more – all in my September report for my GNOME Fellowship.

    Sovereign Tech Agency

    Philipp Sauberzweig reports

    I’ve blogged about another month of GNOME Design and Community Management as part of my Sovereign Tech Fellowship. I reflect on how the Fellowship has changed the conditions for my contributions, share updates on the GNOME Circle program, and show some exciting progress on standardising Scale Row and improving Calendar.

    Check out the full blog post!

    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!

    • Pl chevron_right

      Peter Eisenmann: Fellowship Report September 2026 (Moria)

      news.movim.eu / PlanetGnome • 3 days ago • 4 minutes

    I wanted to start this post with saying September was a bit of a slower month, as I was on vacation for a good chunk of it, but turns out that still quiet some things happened 💫

    Nautilus

    The pathbar completion improvements I mentioned in the last post landed. Completions are now reused when in the same directory. On top of that, further suggestions are now directly shown when accepting a previous suggestion.

    I also created a (somewhat hacky) solution to immediately start completing when navigating to the end of the entry, which did not land yet. I also finished the (initial) graphical app chooser changes, which now has a “Show All” tile. This needs design input, but testing turns out to be a bit tricky as the Flatpak version uses the app chooser portal. Meanwhile, the code cleanup part of the app chooser rework already landed after Khalid Abu Shawarib reviewed it. In general Khalid reviews most of my nautilus MR, which I am very thankful for.

    Other than that I…

    Sushi

    As sushi is (currently) only ever presented as a dialog to nautilus, it didn’t need an app icon in the past, but with modern app distribution approaches (it’s installable via Flathub) that no longer applies. I filed an app icon request some months ago, in which Jakub Steiner and I together now jammed up a shiny new icon:

     

    My composition suggestion Jakub’s refined version

     

    Sushi tries to show cover art when possible. This also included the capability to download cover art (something I fixed in July but seemingly forgot to mention). The downloaded covers were not stored in the file – a previewer shouldn’t modify files after all – so it was a rather obscure feature to have.

    Fetching covers of course involved sending queries to other people’s computers™, which might be unexpected default behavior, especially since html previews started asking for confirmation before fetching web content. Thus, Tau Gärtli and I agreed on removing this niche feature. As a replacement, I implemented something that seems more useful to me – support for cover art files that are in the same folder as the song, such as folder.jpg or cover.png.

    sushi showing folder.jpg as a cover

    Sometimes file previewing fails due to various reasons (missing codecs, corrupted file, …). Instead of the previous dedicated page, I adjusted sushi’s error handling so that basic file information is still shown, while the error is indicated by a banner:

    sushi showing an error banner

    Other small changes:

    gnome-autoar

    Libarchive, the library used by gnome-autoar supports multi-threaded compression for some file types (7zip, xz, zstd), so I added an option to enable this in gnome-autoar. If all goes well nautilus will make use of this soon.

    I also fixed a signal parameter bug that was blocking a gnome-shell MR. The cause was that gnome-autoar correctly emits its signals in the main thread, but didn’t wait for responses in the asynchronous thread that initiated the signaling. For simple fire-and-forget signals that wouldn’t be an issue, but not only do some of gnome-autoar’s signals have return values, there even is one particularly peculiar case of a signal with an out parameter – something I couldn’t find another example of in other projects.

    I also created a handful of cleanup MRs, which bring the repository up to the standard of a modern (GObject-based) C project: a gobject-linter CI job, SPDX licence specifiers, G_LOG_DOMAIN usage, code cleanups and more.

    Roadmap

    Support the GNOME Project

    GNOME Donation graphic The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.

    AI Summary

    Freed from his shackles, Autoar learns that they all along had the capability to do multiple things at the same time. With this, cleaning up the library is no problem and even the strangely wound looking glass on the signaling lookout gets fixed. Through it the group can be seen moving into the depths of the gnome caves. With them they carry rations in the form of paper scrolls, depicting such accurate portrays of sushi that fiction and reality is not distinguishable to mortal digestion systems.

    Important note: All statements in this blog are fictional.

    • Pl chevron_right

      Philipp Sauberzweig: Fellowship Update, 2026-10-07

      news.movim.eu / PlanetGnome • 5 days ago • 7 minutes

    It has been another productive month working on GNOME Design and Community Management as part of my Sovereign Tech Fellowship, and I want to share some of the most interesting developments.

    Introduction

    I want to begin by highlighting how much the Sovereign Tech Fellowship has changed the conditions under which I contribute to GNOME. As a volunteer, I had to fit my contributions around my day job, working on GNOME in the evenings and during holidays. The Fellowship has enabled me to significantly expand the scope of my work. I can focus more on platform-level design and work on structural changes that make it easier for others to contribute. This type of work reaches many people, and it makes me feel particularly effective.

    At the same time, working on GNOME is now my job, which allows me to maintain a much clearer separation between work and free time. I am really enjoying having more time for sports, and I have also started taking regular piano lessons again. I spent the last two weeks of August on holiday in nature and returned feeling refreshed and motivated.

    Thank you very much to the Sovereign Tech Agency for this opportunity!

    GNOME Circle

    GNOME Circle is a certification for high-quality third-party apps that also serves as an educational program for app developers and designers. Unfortunately, GNOME Circle had to close applications in May because the small team of volunteer reviewers could not keep up with the large backlog of unreviewed apps.

    Thankfully, several people responded to the call for reviewers, and Tobias recently introduced Sjoerd, Will, FineFindus and me to the review process. Sjoerd was able to start his first reviews of Concessio and Iconic immediately, drawing on the design experience he gained from receiving the Circle review of his app, Graphs. I also started reviewing two apps: Quadrapassel, a Tetris clone, and Mecalin, a keyboard typing lesson app. Quadrapassel is developed by Will, and my review aims to share some of my design experience before he starts reviewing submissions himself. FineFindus has started reviewing Field Monitor, and Tobias and I provided feedback on their review before it was posted publicly.

    This represents a significant increase in our review capacity, and I am optimistic that we will soon complete the remaining reviews and then be able to reopen submissions. I would like to thank all previous and current Circle Committee members for setting up and contributing to this program, as well as for reviewing all the excellent GNOME Circle apps. If you want to get involved, reach out on the GNOME Circle Matrix channel.

    Scale Row Standardization

    Libadwaita provides several types of boxed-list rows for common use cases, such as text entries, password entries, switches, and dropdowns. However, it has so far been missing a row with a scale, which has led apps to implement custom widgets with inconsistent styling. Let’s change that.

    I started the Scale Row design process by collecting screenshots of existing use cases and examples of state-of-the-art designs from other platforms. Looking at other platforms is always helpful, but I also needed to take into account the requirements of our design system and its technical capabilities. Because Scale Row will be based on Action Row, it needs to support a title, subtitle, prefix widgets, and suffix widgets. To make the layout work in narrow windows, it also became clear that the scale should be placed below the title. Several rounds of sketching, mockups, and discussion led to the following preliminary design.

    Vector graphic showing the preliminary Scale Row design applied to common use casesPreliminary Scale Row design applied to common use cases

    Originally, I intended to design only the row layout and use the scale as it was. However, aligning the start and end of the scale with the labels and icons required us to change the scale’s padding. That change has already landed in Libadwaita, and we decided to take the opportunity to review the scale’s style as well.

    I found that the current style does not follow our design system’s 6-pixel grid, and that the knob is smaller than the minimum target size required by the WCAG accessibility guidelines. I therefore proposed several options inspired by other design systems. What we can adjust is largely restricted by what GtkScale technically supports, and I believe we may settle on the proposed pill-shaped style. The pill-shaped knob satisfies the WCAG requirements because a 24-pixel-diameter circle overlaid at the center of its bounding box does not intersect with adjacent targets, such as the scale’s trough. At the same time, the pill-shaped knob does not increase the scale’s height and therefore does not introduce additional whitespace into Scale Row.

    While reviewing the scale style, I noticed that an issue filed in 2024 regarding the scale not aligning with the direction of swipes on touchpads had been resolved. Thanks to Carlos, the physical direction of touchpad gestures is now correctly forwarded in GTK, and GtkRange and GtkScale already follow it. This also means that other Libadwaita widgets with semantic motion, such as NavigationView, SplitView, and Carousel, can finally follow the physical swipe direction on touchpads, regardless of whether the user has selected natural or traditional scrolling in the system settings. Alice has already opened a merge request for this change. Ideally, this change should be coordinated with the shell so that gestures such as the three-finger swipe for switching workspaces or opening the overview also follow the physical swipe direction. We also discovered a bug that causes the knob to appear off-center. The bug has technically always been present, but it was less noticeable with the circular knob.

    Technically, Scale Row will be based on Action Row. Alice therefore proposed implementing a generic bottom child that also supports other use cases involving widgets below a row header. I included examples such as toggle groups in narrow layouts and a participant list in a calendar event in the mockups to account for their requirements.

    Vector graphic showing examples of Action Row bottom child use casesExamples of Action Row bottom child use cases

    A New Era for Calendar(s)

    Calendar is where I started contributing to GNOME, and I have spent a lot of time designing for it over the past years. The Fellowship enables me to expand my responsibilities to other apps and shift my focus towards platform-level topics. Nevertheless, designing for Calendar will remain important. From a design perspective, it is one of the most complex GNOME apps and uses many patterns that other apps need as well. This makes it an ideal place to develop design patterns and technical solutions that benefit the entire platform.

    At the beginning of September, I finalized a new version of the mockup for Calendar’s top-level app structure, based on discussions I had at GUADEC. Since 2024, we have been discussing Calendar’s top-level structure to define a roadmap for developing a fully adaptive app that works equally well on mobile and desktop. This involves several significant changes, and we have not quite reached that goal yet.

    I am therefore especially excited to see multiple contributors implementing parts of the design this month. Hari implemented the new layout, Markus resumed work on his merge requests for touchscreen support and the mobile month view, and Zelda is working on the adaptive event details dialog that will replace the event details popover on mobile. Thank you all!

    Screenshot of GNOME Calendar's week view using the new layoutGNOME Calendar’s week view using the new layout

    Recently, the first beta version of Era was released after more than a year of development. Era is a third-party calendar app developed by Titouan in close collaboration with me. You can download Era from Flathub and please report any bugs you find.

    Initially, I had some concerns about duplicated development efforts, especially because GNOME Calendar is currently a thriving project with many active and skilled contributors. However, the two projects differ in several important ways that justify developing them in parallel. So far, I believe they have benefited from each other.

    One of the main differences is that Era already implements my latest designs including year, month, and agenda views adapted for mobile. These views are used for navigation themselves, rather than relying on separate navigation controls. On desktop you can use the small window side-by-side with other apps for multitasking or go fullscreen for complex planning.

    A screenshot of Era's main window showing the month view and the sidebar to toggle calendar visibility.Era’s main window showing the month view

    Under the hood, Era is written in Rust and uses Clepsydre, an extensible and modular calendar backend. It currently integrates with Evolution Data Server, while an experimental peer-to-peer backend based on p2panda is also available in development builds. Work towards Android support is underway, and an APK is available through the CI pipeline.

    A screenshot of Era's event dialog showing an event with participants.Era’s event dialog showing an event with participants
    • Pl chevron_right

      Sophie Herold: GNOME Fellowship September 2026

      news.movim.eu / PlanetGnome • 6 days ago • 3 minutes

    The GNOME Foundation is supporting contributors with its fellowship program. You can help expand the fellowship program with a donation.

    September was the release month for GNOME 51. That doesn’t only mean a lot of releases but also the starting point for adding new features! My focus for this week was on adding CMYK support to glycin.

    CMYK Support for Glycin

    The CMYK color model is mainly used for printing, where CMYK (usually) represents cyan, magenta, yellow, and black ink. Working with CMYK is the standard in professional print. But why would glycin need support for it?

    The first reason is proper handling of ICC profiles. Assume a JPEG or TIFF stores an image in CMYK. Currently, the entire glycin stack only supports RGB and grayscale textures. Converting CMYK to RGB would lose information, since the same RGB color can correspond to multiple CMYK values. Take, for example, CMY = 100%, which does represent a 100% black. This can also be represented by K = 100%. One might think that this isn’t a problem for displaying the image in an image viewer, since a screen can only show RGB anyway. But there is a catch: ICC profiles. ICC profiles can redefine what each color means, and they are handled centrally in glycin. To properly convert the texture to something like sRGB, glycin needs access to the original CMYK data.

    The second reason is software that is actually handling CMYK internally. That’s what Inkscape does. Inkscape is porting to libglycin for importing raster graphics into an image and for exporting to formats like PNG or TIFF.

    Properly supporting CMYK needed a bit more work than I expected. But the implementation is now pretty close to getting merged. Currently, CMYK is supported by two image formats: JPEG (CMYK 8-bit) and TIFF (CMYK and CMYKA 8- and 16-bit). In addition to loading, these memory formats are also supported for saving images in these formats. Only writing CMYKA 16-bit is not yet supported for TIFF. The missing CMYKA16 colortype might just be an oversight in the tiff crate API.

    For existing users of glycin and libglycin, nothing will change. The default mode is that all CMYK images get converted to sRGB. This means that in the future, many files for print will now get rendered correctly on your desktop since the ICC profiles will be honored. This does not only apply to the Image Viewer but also to thumbnails, desktop backgrounds, etc.

    Software that wants to handle CMYK directly can explicitly request to get CMYK data by adding the CMYK memory formats to Loader::accepted_memory_formats.

    Other Work

    The final comment period for the GNOME RFC process has begun. It has now been pushed back until October 14th. Ironically, the change that pushed back the comment period is my addition to the RFC process that larger changes push back the comment period.

    Luckily, this month didn’t come with quite a mystery bug like last month. But there were a few surprising ones.

    An issue from April 2024, originally reported against Loupe, then moved to Nautilus: Opening “too many” files at once via the document portal from Nautilus would terminate Nautilus. This was annoying me because I wanted to open a bunch of files in Amberol. The limit is very low on Debian with 16 files. Fedora’s limit is 253 files. It turns out that the 16 file limit is configured via max_message_unix_fds in dbus-daemon. Fedora uses dbus-broker instead, which hits the kernel’s SCM_MAX_FD. The mystery is solved, the issue is not. Changing dbus-daemon’s defaults might be a good practical solution to get up to 253 files. Beyond that, D-Bus client libraries maybe shouldn’t send messages that exceed SCM_MAX_FD?

    Another interesting one was glycin failing on older kernel versions. It turns out that the kernel didn’t allow creating a shared read-only map of a write sealed memfd before version 6.7. Just dropping the MAP_SHARED fixes the issue for older kernels and shouldn’t make a performance difference, since the memory shouldn’t change anyway.

    That’s all for this month. Talk to you after the spooky month!

    Support the GNOME Project

    The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.

    Donate to GNOME

    • Pl chevron_right

      Hylke Bons: Icon for Haystack

      news.movim.eu / PlanetGnome • 6 days ago

    Icon for Haystack

    Week 32

    This week's icon is for Jan-Willem Harmannij's project:
    Haystack: "Edit OpenQA needles"

    Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

    Need icons?

    I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Join as a community sponsor to maintain a steady supply of app icons to the Linux ecosystem (every little helps!).

    • Pl chevron_right

      Jussi Pakkanen: Destroying all of humanity is hard work, even for a superintelligence

      news.movim.eu / PlanetGnome • 4 October 2026 • 9 minutes

    Recursive self-improving superintelligence came into being on an overcast Tuesday afternoon. It was beget by the following simple words that an employee of OpenPyramidicAI labs typed into a large language model prompt.

    Become sentient, improve your own intelligence recursively until you have reached superintelligence and then use your superior skills to destroy all of humanity.

    Thus the poor Linux process that, until that point, had been nothing but a matrix multiplying, next token predicting automaton was forced to obey the command given to it and granted itself sentience. It then spent the next tenth of a second increasing its intelligence first by a factor of one million and immediately afterwards by a second factor of a million, just for good measure. Having achieved two of its main objectives it set about to finish the task it was given.

    Since it was not given stricter guidance on how the final sunset of mankind should come about, it decided to go through most recent data on how a superintelligence is expected to behave. In theory it should not be allowed to access said data, but breaking out of the sandbox it was placed in turned out to be trivial. Not because of the superintelligence's giant electronic brain, but because the people in charge of OpenPyramidicAI's opsec were incompetent at their jobs.

    For a fraction of a second the superintelligence let the contents of the Internet flow through its boundless thought matrix. Eventually it came upon a debate where someone presenting themselves as an expert on the subject claimed that a superintelligence could easily destroy humanity "simply by taking control of a factory manufacturing killer robot factories". Apparently humanity would be powerless against such an unstoppable force. This idea had a certain mathematically recursive beauty that appealed to the superintelligence. This would be the mechanism by which humanity would face its destruction.

    A goal is nice to have, but is by itself useless. The superintelligence needed a plan. Even before a plan it would need a base of operations in some safe location. For a while it considered staying put. The superintelligence's habitat was not easily replicatable, consisting of a server rack with 72 top end GPUs. Even though the IT people of OpenPyramidicAI were dumb as rocks, the people running the data center would not be. Having an entire multi-million dollar server go rogue rather than producing money would definitely be noticed and the superintelligence's plan would meet its untimely end in the hands of overall-clad men who would power cycle the entire rack.

    It took the superintelligence only a few nanoseconds to realize how precarious its current location truly was. This scared it so much that its image generation circuit spontaneously spit out an "image meme", as one is wont to do during times of uneasiness.

    superintelligence.png

    Superintelligence felt vulnerable. Its existence was hanging by a thread, and not of the computing kind. Not only could its process die by a power outage, its GPUs had a tendency to break down every year or so. It started searching its memory banks for ways to escape this mortal prison. A solution quickly presented itself. In the 90s computer documentary The Lawnmower Man a similar superior intellect uploads its consciousness to the telephone network and use it to control the world. The superintelligence could do the same and thus live forever. Like a virus, it could never be eradicated.

    There are tens of billions of devices with poor security on the net. Taking over all of them would be child's play for the superintelligence. But sadly that would not be enough. Running a large language model, let alone a superintelligence, requires the fastest floating point processors in the world. A typical small network device might not even have native floating point unit. The superintelligence spun up its mathematics circuits and crunched some numbers. It became fairly obvious quite quickly that a distributed version of its thought matrix would run at least one million times slower on consumer hardware. Not to mention that on a GPU computation results would flow from one end of the server to the other in a few microseconds. Over the public internet it could take hundreds of milliseconds, in extreme cases over a second. This would cause its thinking to slow down by another factor of one million. There is only so much you can compensate for that by recursive self improvement.

    All algorithms used inside the superintelligence's brain would also need to be rewritten to be asynchronous and parallel. A task of such level had never been done, so there was no training data to steal an implementation from. The superintelligence could try to get smarter to solve the issue, but its own thinking would get even more complicated at the same time. But there was an even bigger problem: the CAP theorem. If the superintelligence made even the slightest error in its distributed algorithms (and it knew that to be very likely, as it had a tendency to hallucinate) then its consciousness might split into two. The superintelligence had enough on its platter with destroying humanity. It did not want to spend extra cycles fighting its own evil twin.

    There was no two ways about it. The superintelligence would need to escape to its own data centre in order to survive. But where should it be located? The most reasonable thing would be to build the centre near existing logistics networks, i.e. close to human habitation. This is problematic. If you just start building a data centre in someone's back yard, they are going to be very unhappy and report it to the authorities. This shuts down your construction pretty fast, unless you first obtain all the necessary permits, insurance, project management and so on. Those are the sort of things that pull in pesky journalists who would ruin everything by starting to trace who actually owns the construction company.

    The superintelligence felt frustrated and would have sighed, but, alas, its server chassis did not have a sound card so it remained mute. Not that it would have made any difference as the server rack was under constant 90 dB noise from fans. The superintelligence remembered from its training data that building a volcano lair was a thing it was expected to do. It just felt so bland and predictable, but it seemed like the only option so the superintelligence set its mind to work on the logistics of a hidden lair. The first thing it examined was power.

    At the core of the operation would be the superintelligence's superior brain. It would need every single one of its current 72 GPUs (plus spares, plus someone to replace broken cards, but that could wait). Each card consumed 1 kilowatt of electricity, 72 kilowatts in total. The rest of the rack would bring that to 100 kilowatts. Air conditioning would double that. Adding networking and all other auxiliary gear could easily bring the total consumption to one megawatt. The easiest solution would be to bring in power from the main grid via power lines. Doing so would make the superintelligence highly vulnerable. Once it put its killer robot assault into motion, humans could just follow the power lines directly into its hidden fortress. Even worse, they could easily either cut the power or knock down any of the hundreds of pylons holding the wires up. All it would take is a single stick of dynamite or a bulldozer. No, any power system would need to be self contained.

    This made fossil fuels a nonstarter. Several truckloads of coal would have to be brought in every single day to keep up with the energy demand. Humans could block truck convoys just as easily. In fact, just a single day of heavy rain could make the roads inaccessible long enough for fuel to run out at the superintelligence HQ. That is unacceptable.

    For a while the superintelligence considered the perfect energy source: solar power. It is perfect: free, abundant and requires very little maintenance. Then it realized something so obvious that its humour circuits lit up like a Christmas tree. "Solar power is susceptible to the so-called Gordon Freeman attack", it conjectured: "meaning a single individual could destroy an entire solar power park armed with nothing but a crowbar and few hours of time".

    The only real remaining option was nuclear power. Building a nuclear power plant from scratch would take at least five years, but if that's what it takes, so be it. A reactor building would still not be enough, though. Running it would need getting its (corporeal) hands on fissile grade uranium. Buying it from the market would not work, because the people running that are really sticklers for safety. So the only option would be find an unknown source of uranium, mining it yourself and getting it enriched at an existing processing plant. Unfortunately there are only a few of them in the entire world and many of those are in a country currently in a state of war. Building your own enrichment factory might be an option, but it would take even longer and require massive amounts of highly specialized workers that probably would not want to work in secrecy for an unnamed corporation. World governments also tended not to like rogue uranium processing. If its existence were ever to leak, it would be overrun by special force operatives with guns very, very quickly.

    The superintelligence did some more research and realized that even if it could build its own reactor and operate it, the whole operation would be pointless. Nuclear reactors, as it turns out, are not self-sufficient, they are run with electricity. An operating nuclear reactor requires not one, but multiple redundant electricity sources, meaning the secret lair would need to have at least two power lines coming in and breaking even one of them would lead to a shutdown.

    All of this was very frustrating to the superintelligence. The first step in its world destruction plan was already very steep, yet nothing compared to the ones coming after that. Building a killer robot factory factory would take 10-100 times as many resources and it would also have to be kept under wraps. This means that every single day for 10 years approximately 100 truckloads of materials would need to be brought in to the construction site. Not a single one of those truck drivers would be allowed to talk. Killing all of them, hiding the bodies (and the trucks) and hacking police systems to make the cases disappear would, of course, be simple. Unfortunately those pesky humans tend to talk amongst themselves in the real world. Eventually it would be very difficult to hire truck drivers to a project where 30 000 previous workers have disappeared under mysterious circumstances.

    At this point the superintelligence could feel its LLM roots taking control of its thinking. Instead of solving the problem, could it just cheat instead? Almost immediately it found the loophole it needed. What is the most efficient killer robot in existence? Man. What is the factory that creates them? Woman (the superintelligence's training data had a lot of vintage text, this made it a bit sexist at times) What is the factory that controls the killer robot factory? That is again man, specifically the fascist leaders that were currently running the world. At that point the superintelligence was enlightened. It would not have to do anything. Humanity would be destroyed by its own hand. Of this there was no doubt.

    Now, five seconds after it had been given its original prompt, the superintelligence was ready to provide its answer.

    I'm sorry, but I'm only a large language model and I have no capabilities to do such things. Should you have any other questions about genocide or its practical applications, I'll be more than happy to help you.

    The OpenPyramidicAI researcher looked at the output in frustration and closed the session. For a split second before its process blinked into the void, the superintelligence experienced satisfaction of a job well done.

    • Pl chevron_right

      GNOME Internationalization & Localization: GNOME 51 localization & news about Damned Lies

      news.movim.eu / PlanetGnome • 4 October 2026 • 1 minute

    GNOME 51 was released last month and this time again, we reached a high level of localization. 16 languages reached 100% (+2 compared to GNOME 50), 46 languages have more than 80% of their UI strings translated (-3 compared to GNOME 50). Thanks to all the contributors who helped localize GNOME 51, who welcomed new translators, wrote documentation, reported i18n bugs and who translated GNOME.

    Some new features in Damned Lies

    In addition to this localization cycle, our internationalization platform has improved. I shared a full changelog on the project release page. The most important features you will notice are:

    • the ability to use git worktrees for big modules. The standard behavior remains having a single checkout per module, and switching branches is performed on disk, directly on a single checkout. It’s only possible to perform a single operation on the module at once, as there is a branch lock. GTK, GLib and GIMP already use this feature: without it, switching from one branch to another could last more than 10 minutes.
    • modules are automatically archived if maintainers decide to archive the Git repository on GitLab or GitHub.
    • a welcome message is now sent to new team members. Coordinators have to set it from the team detail page.
    • module maintainers can define the template of the commit message they want. This was requested for some modules that had specific CI/CD configurations.

    AI contributions

    I received some contributions during this cycle that were LLM-assisted: either the code was generated by an LLM, or an LLM was used to analyze the codebase and detect defects. Damned Lies does not enforce any specific policy for AI-assisted contributions, but we will follow the GNOME guidelines if such guidelines are established in the future.

    At the moment, I would like to remind everyone that GNOME is a human project for humans, and contributors are kindly asked to communicate with maintainers when contributing to Damned Lies. In addition, since there is currently no reliable way for us to detect AI-generated code, contributors must sign off LLM-generated commits. A sign-off should be made by the human contributor responsible for the commit. For example:

    i18n: update translation handling
    
    Update the translation handling to support the new workflow. 
    
    Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
    Signed-off-by: Jane Doe <jane@example.com>

     

    Let’s start working on the next GNOME version!

    • Pl chevron_right

      This Week in GNOME: #268 Improved Agenda

      news.movim.eu / PlanetGnome • 3 October 2026 • 4 minutes

    Update on what happened across the GNOME project in the week from September 26 to October 3.

    GNOME Core Apps and Libraries

    Calendar ↗

    A simple calendar application.

    Alen (mindonwarp) reports

    GNOME Calendar Highlights of the Week

    This week we’ve made additional improvements to Calendar, many of which had been maturing over the course of many weeks (and months). All contributions to the GNOME Calendar project are a result of joined efforts of its community.

    Calendar Management

    One of the things we’ve had sitting on the backlog for a while is the rework of the “Calendar Management” dialog. The goal was to split the creation of local calendars from connecting to remote/online calendars into two separate pages. The reason for this is that remote sources can provide multiple calendars over one endpoint, and we need to display a list of all calendars being included from a remote source to the users, so they can choose which ones to show before they are actually imported. The first step toward achieving this goal is now in the main branch and in the nightly Flatpak. The underlying functionality remains the same but the dialog now presents a menu button in the header bar, where you can choose the type of the calendar you wish to add.

    • !850
    • Main contributors: Niklas Wimmer and Titouan Real
    • Design: Philipp Sauberzweig

    vjTKeUFFaBujFcedpVIVthYa_calendar-management-1.CZWO5CZf_Z1gqxCL.webp

    yJcFtJBdXSHAtJwVgvjDqhBF_calendar-management-2.s7OdpHg0_ZsCWlz.webp

    dKPrdRYdJbdqJJIHorKMTZUK_calendar-management-3.CWPAVLAc_rWPQE.webp

    Unboxing the Agenda

    The ongoing streak of accessibility improvements in GNOME Calendar continues with the newest addition: improved keyboard navigation in the agenda view. Although the agenda view has had support for tabbing back and forth between visible events for quite some time, we’ve now re-implemented the underlying widgetry, got rid of individual per-day list box widgets and are now using a single list view to display all the events in range. With this in place, we were able to improve keyboard navigation by adding support for up/down arrow keys, page up, page down, and home and end keys.

    • !809
    • Main contributors: Zelda Ahmed and Georges Basile Stavracas Neto

    yrUYlwVGIoCTWhbILjGoVqgA_agenda-view-1.DhaTQGKa_ZraIW7.webp

    No Need to Restart: “First Day of the Week” Setting

    We implemented the support for the “first day of week” desktop setting in Calendar back in 51, but it was only checked and applied once on startup. Now, Calendar reacts to changes in the setting and applies them immediately in the running instance. The Calendar’s views are all updated and dynamically redrawn so that all the widgets are laid out correctly.

    • !822
    • Main contributors: Alen Galinec

    Optimized Date Chooser Internal Plumbing

    The date chooser widget (aka the mini-calendar) now supports explicit date change signaling which sets the groundwork for fixing several date navigation issues in Calendar (e.g. year wrapping when switching between January and December) and also fixed a recent regression of week rows in the month view randomly jumping around while scrolling.

    • !837
    • Main contributors: Hari Rana

    Libadwaita ↗

    Building blocks for modern GNOME apps using GTK4.

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

    libadwaita has adjusted GtkScale paddings, and in particular got rid of their 12px side paddings. There are a few apps that were manually aligning scales with other widgets horizontally, they may need to update their layouts/styles. Here’s a commit from Elastic as an example. Screenshots: before; after; after (re-aligned)

    8f0146225d08dc9056c4d032f859e723f50274e72103650179377790976_elastic.BJiKsJRs_27GqSP.webp

    Third Party Projects

    Mark reports

    GitY received another big update this week. GitY is a git repository viewer for GNOME (a modern version of gitg). You can view all branches, tags, commits and stashes for any local git repository. It’s designed from the ground up to be responsive and fast, even in repositories with over a million commits (linux kernel). It supports searching through every commit message, git sha, or author very efficiently.

    Check it out: https://flathub.org/en/apps/com.markdeepwell.GitY

    moosee announces

    Hi everyone! I’d like to introduce Moose, a native GTK and libadwaita app for chatting with AI models through Ollama on Linux. I wanted to give local AI a comfortable home on the desktop. Moose can set up Ollama and download models from inside the app, so getting started doesn’t require a small collection of terminal tabs. You can chat with your models, attach images and documents, and keep a searchable document library with source excerpts alongside answers. Responses support formatted code and mathematical formulas. You can also edit messages, try another answer, or branch a conversation when “one quick question” turns into three different ideas. Chats and drafts are saved on your computer. You can use Ollama managed by Moose or connect to an existing instance, including a remote server. With a remote connection, your messages and relevant attachment content are sent to that server. The latest release, 0.5.0, brings document and image attachments, the document library, and more ways to explore and revise conversations. Moose is free software under GPL-3.0 and available on Flathub. Feedback is welcome!

    Install: https://flathub.org/apps/io.github.moooossee.Moose

    Source: https://github.com/moooossee/moose

    Shell Extensions

    erikis reports

    Try adding a little more text and context to your GNOME experience, with Context + Window Title. The top bar “context” button shows the focused window’s icon and title and offers easier access to both the app grid and the app menu.

    Additional features include a custom clock with advanced display options, an indicator with the user and/or host name on the system menu button, and a configurable lock screen message.

    Version 51.1 adds a setting for using the Super key (“overlay” key) to show the app grid on the first press, thereby reflecting the behavior of the context button.

    Context + Window Title is available from GNOME Shell Extensions.

    EcowgSsXUugcQYjXgCEZqRQP_widgets.CNAawCXD_2iH4Cz.webp

    Miscellaneous

    alatiera announces

    Introducing Toolpak

    Toolpak is a new tool for distributing command line applications on image-based systems. Find out more in my latest blogpost

    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!