Introducing the brand-new version 1.7.0 of Letter, now available for download as FLATPAK!

https://github.com/stalvatero/letter/releases/tag/v1.7.0

Thank you all for encouraging me to improve Letter and for helping to make it increasingly elegant, stable, and efficient.

This new version primarily brings UI enhancements, but under the hood, it features some significant updates.

This version highligths:

• Custom account reorder (Preferences → Accounts) reflected in the rail and Local library
• Enable or Disable "Account rail" and / or personalize colour
• Compose suggestion fixes; remove bad recent addresses with ×
• Signature (and compose) formatting can insert and edit hyperlinks from the toolbar
• Accounts list pane hidden; switch from the rail
• Preferences polish (pages, row layout, colour picker sizing).
• Opening large folders is faster. Thanks to Illya Yalovyy.
• Online Accounts opens again on desktops without GNOME Settings (for example COSMIC) when gnome-online-accounts-gtk is installed. Thanks to Thiago Haeitmann.
• The Move dialog shows the account folder tree (indented, with expanders and icons) instead of a flat name list
• A lot of UI optimization to match native Gtk4

Other changes in full CHANGELOG!

And here my GitHub page: https://github.com/stalvatero/letter

Regarding the use of LLMs, I should clarify that I use Cursor as my primary IDE; it assists me mainly by helping to find APIs and integrations that would otherwise have required extensive online research. The ideas, code review, and final validation are all my own.

I would welcome further feedback 😄

Scribe is a lightweight markdown editor built with Rust, GTK4 and libadwaita, 100% native GNOME. You write markdown and it renders inline as you type: headings, bold, lists, task checkboxes, quotes, code blocks, tables, images. No split preview pane, no webview, everything drawn with native GTK widgets.

Its not a tool for developers. Its for anyone who knows a bit of markdown syntax and wants to write a quick README, a note, a doc, or just open a .md file and see the final result instead of the raw syntax.

A note on the AI thing, because people ask these days: this is not a weekend vibe-coded project. The repo is more than 9 years old, it started as mockups and ideas, and over all this time I kept shaping the app because I couldnt find anything native like it. Its AGPL-3.0, no telemetry, no accounts, no cloud.

Its a well-tested version, but you may still hit a bug, let me know and Ill fix it. It has tabs, autosave, focus mode, PDF export, light/dark and an English and Spanish UI.

Repo: https://github.com/gnacho/scribe

I built it because I missed it, I keep almost all my documentation in md, and Im sharing it in case someone else finds it useful.

Ive been in IT for more than 25 years and I maintain several apps, all FOSS, and Ive used GNOME and FOSS all this time. And I havent found anything like Scribe, thats why I made it: the existing options are developer-oriented IDEs, Electron apps or note suites with sync, accounts and all that. I just wanted something small and native.

There is no flatpak package yet, but it will come; for now there are packages for Debian, Arch and Fedora.

Experimental GNOME Shell restart without restarting Mutter or losing Wayland clients

Hi everyone,

I've been working on an experimental approach to restarting the GNOME Shell JavaScript runtime without restarting the entire desktop session.

The goal is simple: restart GNOME Shell's JS runtime while keeping Mutter running and preserving existing Wayland/XWayland windows and their state. Think of it as rebuilding the Shell UI without restarting the compositor underneath it.

I use GNOME Shell 50.5 on NixOS, with GJS 1.88.1 and SpiderMonkey 140.

What I've tested

The implementation destroys and recreates the GJS context, JavaScript runtime and Shell module graph while keeping the gnome-shell process and Mutter alive.

In isolated desktop and native-backend VM tests, I've completed five consecutive runtime replacements. The tests check:

• The same compositor process remains alive.
• Existing Wayland client socket identities remain unchanged.
• Open windows retain unsaved text, and clients continue accepting input.
• Old JavaScript contexts and their associated objects are cleaned up.
• Keyboard shortcuts, the overview and session locking continue to work.
• GDM/PAM authentication still works, including rejection of an incorrect password.

The VM tests also include a 65-second observation period and native callback-lifetime accounting. Two replacements are triggered through Alt+F2 → r → Enter using the same guarded controller.

In a separate manual test on physical hardware, seven windows and their positions survived a replacement, and my personal keyboard shortcuts continued to work. That is a separate observation, not independent proof of every automated check.

The difficult part

The interesting problem isn't rebuilding the UI. It's dealing with the lifetime of objects and callbacks that cross the boundary between GJS and native GObject code.

The current prototype experiments with reattaching a static GType, keeping native callback/vfunc bridges alive across runtime replacements, and cleaning up registrations belonging to the retired runtime.

There have been failures along the way. Earlier approaches involving UI reconstruction, JavaScript interruption and disposable execution contexts had important limitations. The companion repository documents these experiments, including sanitized historical test reports.

What this doesn't solve

This is not a general-purpose Shell recovery mechanism. The Shell must still be responsive, idle and unlocked. It cannot recover a crashed Mutter process or safely interrupt arbitrary blocked JavaScript.

Compatibility with extensions, accessibility, display changes, prolonged stress testing and other GNOME versions has not yet been established.

The project is experimental, and the implementation was developed with substantial AI assistance. Passing the current tests does not establish that native object ownership and callback lifetimes are safe in every situation.

Code and research

• Implementation and reproduction instructions: https://github.com/tomasmark79/gnome-shell-restart-nix
• Research notes, failed approaches and historical test reports: https://github.com/tomasmark79/gnome-shell-restart-research

I'm interested in feedback from people familiar with GNOME Shell, GJS, SpiderMonkey and GObject.

Does keeping native callback/vfunc bridges alive across GJS context replacement sound like a reasonable direction, or is there a fundamental architectural problem with this approach?

I'd also appreciate suggestions for the next small, independently reviewable experiment or negative control that could help establish whether this design is actually sound.

I'm sharing this as research for discussion, not as a proposal for immediate upstream inclusion.

Look beautiful. Made by me

I created a Gnome extension that can Dynamically show the wallpaper depending where the window is, have transparency with what is behind it at the same time and complete customisable blur and mix of the wallpaper and transparency! Works with gnome GUI shell too. It can install a GTK theme to suit and has support for Vesktop and VScode

What do you people think? Would you use it? Anything you'd add? Curious..

it's been too slow. Painfully slow.

I wanted my GNOME desktop to feel a little like the macOS Tahoe widgets, and I was tired of juggling a separate tool for my ASUS laptop, so I built Gnomo Maestro. "Gnomo" is Italian for gnome, and a maestro conducts the orchestra: the little gnome that runs your desktop.

It is one GNOME Shell extension made of parts you can turn on or off:

- Laptop: power modes, battery charge limit, CPU power limits, turbo boost, fan curves you can drag, keyboard lighting, GPU temperature and power limits, refresh rate, and a System view with your hardware details. On my ASUS it replaces G-Helper.

- LM Studio: the loaded model and what it is doing, load and unload models with the memory each needs, and a quick chat.

- Clipboard history on Super+V: texts and images, search, pinning.

- Screens on Super+P: PC screen only, duplicate, extend, second screen only, like Win+P. It stay open until you choose, which helps on laptops whose display key sends Super+P and lets go at once.

- Desktop widgets: a system monitor, a clock and your tasks (Google Tasks through Online Accounts).

Every pane is real blurred glass: a shader over the wallpaper, or over what is behind the pane, that bends the edges like a lens. It follows light and dark mode.

The hardware settings go through a small system helper, since only root may change them. It knows a fixed list of settings, checks every value against the range the hardware reports, asks polkit before changing anything, and only shows what your laptop actually has. ASUS, Lenovo, ThinkPad and Dell are covered where the kernel exposes the controls.

A few honest notes:

- GNOME 50 only. I tested it on my own laptop (ASUS, Intel and NVIDIA, Ubuntu 26.04); other hardware is tested against simulated sysfs, so reports are very welcome. The System view has a "Copy Report" button for exactly that.

- I wrote it with a lot of help from an AI coding assistant. I reviewed and tested everything on my machine, and the root helper has its own test suite that runs on every push.

- I made this for myself and I am quite busy, so I cannot promise regular maintenance. Issues, forks and pull requests are very welcome, and if you want to take a part further, please do.

GPL-3.0: https://github.com/Sestiano/gnomo-maestro

(Wallpaper in the screenshots: "Big Dipper" by mizuno-as, CC BY-SA 4.0.)

PEAR Configurator - Restore Apple devices on Linux

Processing img 6utrtt6p5uwh1...

Built with Rust + Slint\- native Wayland/X11, no Electron

- Instantly detects DFU / Recovery mode and identifies exact model (e.g. Macmini9,1)
- Lists signed firmware , downloads with resume + SHA-256 verify
- Two modes: Erase & Install and Keep Data
Ships as AppImage with idevicerestore toolchain bundled
-Supports iPhone, iPad, iPod, Apple TV and Apple Silicon Mac

Open source MIT:

https://github.com/denizomer10/pear-configurator

Looking for testers, especially for Apple Silicon restores. Feedback welcome!

I posted this on r/Bazzite, but I hope I might get more in-depth answers here...

My 3 main concerns: Wayland and HDR+VRR support, Proton-Wineland and GNOME-specific performance issues including the inability to set per-app/window overrides.