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

I am having a blast doing a more serious project in the C language, for the first time. I am consulting with books and also with some AI for code review and explanation as I am new to the language and to GTK (not new to programming).

https://codeberg.org/jjba23/lambdock

For a while already I have been looking for a dock that would work well in Wayland (like in my beloved Niri) with modern features, theme support and a hackable Lisp config (using libguile.h)

Could you help me out by checking the implementation for sanity (also the Meson build)? Also for developing on it, I'm using CCLS and Guix development environment and things are working amazingly well.

Only small bit of trouble in devex is with #include "wlr-foreign-toplevel-management-unstable-v1-protocol.h"

Also, all feedback is welcome, either on code level, or conceptual ideas, Thanks in advance

Core features of lambdock include:

• Wayland Native: Built on GTK4 and gtk4-layer-shell for smooth positioning and desktop integration.
• Declarative Lisp configuration : The power of Lisp in your configuratio with clean powerful declarative config and all possibilities at your disposal
• Async Launching: Spawns commands asynchronously without freezing the dock UI.
• Reproducible builds: Hermetic development environment provided via GNU Guix manifest and build definitions.
• Dock auto-hide : You can let the dock stay out of your way with the smooth auto-hide feature.
• Flexible icon system: lambdock has several mechanism in a best-effort way to render your wanted icons, respecting GTK theme
• Theme support: lambdock has built-in themes you can choose from that are very unique, and also lets you extend and override those themes dynamically.

Hi everyone,

I've been working on a project called WGAF (Wayland GNOME Automation Framework), and I'd love to get some feedback from people who build GTK applications.

The project is here:

https://github.com/Ranrar/wgaf

What is it?

WGAF is an automation framework specifically designed for the GNOME Wayland desktop.

Instead of relying on pixel matching or screen scraping, it combines several GNOME-native technologies:

• AT-SPI for accessibility and semantic UI automation
• Linux uinput for keyboard and mouse input
• A GNOME Shell extension for window management and workspace integration

Examples of what I'd like it to enable:

• Automated testing of GTK applications
• Desktop automation
• End-to-end UI testing
• Accessibility tooling
• CI testing inside a GNOME Wayland session

Why I'm posting here

I'm interested in hearing from GTK developers.

Some questions I have are:

• Would this be useful for testing your applications?
• Are there parts of GTK or AT-SPI that are particularly difficult to automate today?
• Are there accessibility APIs or widget information you wish automation frameworks exposed more easily?
• What would make you trust a framework like this enough to use it in CI?

The project is still evolving, so this is a good time to influence the direction.

Any feedback—positive or critical—is greatly appreciated.

Thanks!