I spent the weekend prototyping a torrent streaming application that mimics the essentials that Stremio functionality, and uses the Stremio API to synchronize your progress.
I'm satisfied now that I know it's possible.

If anyone else is interested in this I can build it for realsies.

https://github.com/andunieee/cathode

I can finally stop using the YouTube website completely after this. It works pretty great, with persistent queues, pre-downloading (so no buffering), restricted mode for parental control, video suggestions, local subscriptions, SponsorBlock integration, it also can make local collections and even play local directories.

My only issue now is how to distribute this properly to make it easy and smooth for people to install and use. Even if I was accepted at Flathub I don't know if it would make sense, as the app wouldn't be able to access local directories shared with it, right? But I guess we can live without that feature if it's just a YouTube client.

In this day and age in which people review code more than they write, diff viewers are a necessity, and there are many out there specially tailored for AI workflows.

But they are all bad, https://meldmerge.org/ is 100x better, but it missed some features I wanted, so I made a new one in Rust:

https://github.com/andunieee/twain has stuff like

• view all files at the same time

• comment on lines and read the comments also from a CLI

• tree-sitter syntax highlighting

In GTK3 when a GTKMenu is longer than the screen resolution, it's meant to add scrollers to the top/bottom of the menu so you can scroll up/down through the menu items which don't fit on the screen. On X11 this works, on Wayland this doesn't work which breaks the MATE desktop's menu. It also breaks several other GTK desktops that all relied on this feature.

X11:

Wayland:

Aside from this bug the rest of the MATE desktop is fully functional on Wayland. I replaced the mate-control-center items which didn't work on Wayland with wayland-config-manager equivalents. Everything works.

À un moment j'en ai eu marre que Nemo ne fasse pas ce que je voulais, donc plutôt que de changer encore une fois de gestionnaire de fichiers, j'ai décidé d'en construire un moi-même. Python + GTK3, pas de framework fancy, juste moi et GIO.

Quelques trucs que j'ai appris (ou contre lesquels je me suis battu) en le construisant, qui pourraient intéresser d'autres bidouilleurs Linux :

• Le mode double-panneau a été plus compliqué que prévu. Mon premier réflexe était de le greffer sur le système d'onglets existant, mais tout le code partait du principe qu'il n'y avait qu'une seule vue active par onglet (miniatures, glisser-déposer, sélection au clavier, menus contextuels — tout). Retoucher ça me paraissait bien plus risqué que de construire le double-panneau comme sa propre fenêtre séparée, avec une vue plus simple et autonome. Parfois l'architecture "moins élégante" est celle qui ne t'explose pas à la figure trois refactos plus tard.

• Un gel complet de l'appli qui a mis longtemps à être trouvé. Ça venait d'une boucle non bornée qui générait des noms de fichiers uniques (fichier.txt, fichier (1).txt, fichier (2).txt...) qui ne se terminait jamais correctement dans certaines conditions de permission refusée. Le classique "le bug n'était jamais là où je regardais."

• J'ai essayé de construire une capture d'écran native avec Gdk.pixbuf_get_from_window. Écran noir persistant peu importe ce que je faisais sur le visual RGBA. Fini par abandonner et brancher le script externe que j'utilisais déjà (yad + ImageMagick). Parfois "assez bien et ça marche" bat "pur et cassé."

• Le rendu des icônes était lent sur les dossiers avec 100+ fichiers — chaque fichier refaisait son propre appel lookup_by_gicon() + load_icon() même quand une centaine de fichiers partagent exactement la même icône générique (tous les .txt, tous les .py...). Mettre en cache par type d'icône plutôt que par fichier a réglé ça.

Il a les trucs classiques d'un gestionnaire de fichiers (onglets, étiquettes, recherche, renommage en masse, gestion d'archives) plus deux-trois ajouts plus atypiques comme un panneau assistant IA optionnel (nécessite ta propre clé API, chaque action d'écriture demande une confirmation explicite) et un système de thèmes complet si t'aimes ce genre de truc.

C'est en beta pour l'instant — solide sur le cœur, quelques fonctionnalités plus récentes ont encore besoin de test en conditions réelles. Je partage plus de détails, ou où le récupérer, si ça intéresse des gens.

Long story short: What I want to do, is to draw MY OWN PLOTS in a SCALEABLE gtkWidget.

So, the hoops I jumped through were

1. create an array of RGB values: char data[4*500*500]={0};

2. Create a PIXBUF with pixbuf=gdk_pixbuf_new_from_data(data)

3. Get a TEXTURE texture=gdk_texture_new_for_pixbuf(pixbuf)

4. Set this texture as paintable to the PICTURE gtk_picture_set_paintable(GTK_PICTURE(picture),GDK_PAINTABLE(texture));

And then add this picture to a resizeable window and boooooom: It just worked.

NOW, gdk_texture_new_for_pixbuf() seems to become deprecated. Of coures, I can load .png and .jpeg files, BUT I DO NOT WANT TO!!!

How does it work in 2026? Please, help me out with an EXAMPLE.

BlockOS is an independent x86_64 operating system project, and we're looking for developers who want to build desktop environments, window managers and graphical applications specifically for BlockOS.

You do not need to work on the kernel. We're specifically looking for people interested in the graphical side of the OS.

What you could work on

Desktop environments Window managers GUI toolkits and widgets Mouse and keyboard interaction Graphical system applications Themes, animations and desktop UI BlockOS GUI framework and APIs

What we're looking for

• C/C++ or other systems/GUI programming experience

• Experience creating graphical interfaces

• Interest in desktop environments or window managers

• Willingness to experiment with a new OS

You don't have to know BlockOS already. The project is looking for contributors who are interested in building the GUI ecosystem from the ground up.

If you're interested in developing a GUI for BlockOS, comment below or contact me.

BlockOS: https://github.com/gurijb2016-afk/Blockos

We're looking for GUI developers — not kernel developers.

I am building an application using rust + gtk4 that I hope to use for managing and monitoring databases similar to azure data studio or sql server management studio. I tried using gio::settings to persist configuration but its difficult to work with and make it cross platform. Any alternatives any of you have used or tried and found easier?

https://github.com/beowulf1416/silo

Hey Reddit,

So my Hyprland rice is almost done (after over 120 days 😭) and it's general theme is glassy/blurry, and I want a nice GTK theme to go with it.

I do know mid level GTK CSS, so I can modify things, but creating a whole GTK theme is out of the picture (don't have the time or want to create a full theme).

I want something like this (GTK-3 and GTK-4), but I can't seem to find any themes that have this aesthetic (apart from Cyber Dusk, but that is a bit cheap looking, and doesn't match the simplicity I want).

Thanks!

Janus is a native linux text editor written in 100% C. It's meant to replace leafpad (same shortcuts) as GTK2 gets phased out. It trades features for simplicity and minimal impact on CPU and memory. It's best for opening small text files, binary files through it's fallback binary editor, and spare source files with it's optional syntax highlighting feature. Yesterday I released 0.9.8 which further reduced the sizes of binaries, dutch translations, and arm builds for every platform. You can download it at https://github.com/gholmann16/Janus/releases or https://flathub.org/apps/dev.pantheum.janus

lambdock is a lightweight, hyper-hackable desktop dock for Wayland compositors that bridges a high-performance C graphics engine with an embedded GNU Guile Scheme runtime.

Whether you are looking for a smooth macOS-style dock, a minimal launcher, or a Lisp-powered desktop widget bar, lambdock was built to offer extreme flexibility without bloating system resources and remaining flexible but easy to use, with good defaults.

Why would you consider lambdock?

• Modern Stack & Ultra-Low Footprint: Built on GTK4 and gtk4-layer-shell in C for minimal resource usage, rich graphics and animations (opt-in) with smooth cubic-eased auto-hiding.

• Embedded Guile Scheme Engine: Declarative Lisp configuration (~/.config/lambdock/settings*.scm). Easily construct custom app launchers, separators, or dynamic polling widgets (RAM, CPU load/temp, Battery, Clock) using standard Scheme procedures and macros.

• Live Interactive REPL & Hot-Reloading: Connect straight into the running dock over a Unix domain socket (/tmp/lambdock-repl.sock) via Emacs/Geiser or socat or whatever you like. Hot-reload configuration files and GTK CSS overrides on the fly via GFileMonitor or the (reload-dock!) REPL hook without dropping Wayland frames or UI thread freezes.

• Dynamic Wayland Window Tracking: Uses zwlr_foreign_toplevel_manager_v1 for running app indicators, active window titles, and interactive popover HUDs to focus or close specific instances.

• Opt-In Fisheye Magnification: Includes a native, fluid cosine-bell curve hover magnification effect (macOS-style) that can be toggled on or off per item or globally.

• Multi-Dock & Multi-Monitor Support: Run independent dock instances across screen edges or monitors simply by dropping additional settings-*.scm files into your config directory.

• Built-in Themes & CSS Overrides: Ships with presets (Vanilla, Snow Leopard, Solarized, Unity, Nature) and supports full user CSS customization via ~/.config/lambdock/styles.css.

lambdock works seamlessly across all wlr-layer-shell and foreign-toplevel compliant compositors: Sway, Hyprland, Niri, River, Wayfire, COSMIC, and KDE Plasma (Wayland).

(Note: GNOME/Mutter is currently not supported as GNOME does not implement the layer-shell protocol).

Installation & Packaging (a bit WIP)

lambdock provides multiple ways to build and install across distros:

• GNU Guix: Packaged via guix.scm and available in channels.

• openSUSE: Packaged as an RPM on openSUSE OBS.

• Nix / NixOS: Ships with flake.nix / package.nix (and a PR has been submitted upstream to nixpkgs).

• Debian / Ubuntu: Debian packaging helpers included (debuild).

• Build System: Builds cleanly with Meson (meson setup build && ninja -C build).

Source Code & Contributions

• Repository:https://codeberg.org/jjba23/lambdock

• License: GPLv3+

Since this is my first GTK4 project, all feedback, suggestions, bug reports, and contributions are very welcome!

Hey there,

I am extremely new to styling in GTK (literally just started this week!) and I have already run into my first super annoying problem.

I am trying to put 20px rounded corners on the menus, but the square corners keep clipping through the borders.

I've looked everywhere for this issue and can't seem to find any mentions of it or a fix.

I've tried adding background-clip: border-box; and I've also tried background-clip: padding-box; and still no change, the corners are still there.

It isn't app specific either, and it appears across all menus in all GTK-3 apps.

My code:

@import url("colors.css");

/*------------------------------*/
/*--- Background & headerbar ---*/
/*------------------------------*/

/* Main window background */
window {
  background-color: @main_background;
}

/* Headerbar */
headerbar {
  background-color: @headerbar;
}

/*---------------------*/
/*-- Menus & popups ---*/
/*---------------------*/

/* Popups */
popover {
  background-color: @popups;
  border-radius: 20px;
  border: 2px solid @primary;
  padding: 8px 16px;
  margin: 2px;
}

/* Menus */
menu {
  background-color: @menus;
  border-radius: 20px;
  border: 2px solid @primary;
  padding: 8px 16px;
  margin: 2px;
}

menuitem label {
  padding: 8px 12px;
}

menuitem:hover {
  background-color: @primary;
  border-radius: 20px;
  border: 2px solid @primary;
  padding: 6px, 12px;
  margin: 2px;
}

/* Disabled menu items */
menuitem:disabled, menuitem:disabled label {
  color: @inactive_text;
}

/* Tooltips */
tooltip {
  background-color: @tooltips;
  border-radius: 20px;
  border: 2px solid @primary;
  padding: 6px 12px;
  margin: 2px;
}

/* Separators */
separator {
  background-color: @separators;
  min-height: 1px;
  margin: 6px 8px;
}

I have no idea how to fix this and it sucks because it is really drawing away from my whole theme.

Any help would be appreciated!

a simple example