Post B2XlH3drmCJKd2hPwe by floooh@mastodon.gamedev.place
 (DIR) More posts by floooh@mastodon.gamedev.place
 (DIR) Post #B2XVh5S44XHSVIZKjY by floooh@mastodon.gamedev.place
       2026-01-22T08:48:56Z
       
       0 likes, 0 repeats
       
       Missing server-side-decoration in Gnome is essentially why sokol_app.h has no Wayland backend and instead relies on XWayland to draw the window decorations (at least that way it's consistent with the other windows).... such a simple and obvious thing held back by stupid stubborness of the Gnome team...https://blister.zip/posts/gnome-ssd/
       
 (DIR) Post #B2XVh6ktE1vuXyNsiO by shironeko@fedi.tesaguri.club
       2026-01-22T09:57:45.191816Z
       
       0 likes, 0 repeats
       
       @floooh I suppose one solution would be to have wayland backend for modern desktops and X backend for legacy X and mutter desktops?
       
 (DIR) Post #B2XlGvdZXPK1noV4NM by floooh@mastodon.gamedev.place
       2026-01-22T10:26:31Z
       
       0 likes, 0 repeats
       
       @shironeko that would be a technical solution yeah, but it adds too much maintenance overhead and redundancy. I'd rather only have a single backend on Linux.I wouldn't call the Xlib "legacy", it's just another window system client API and XWayland is just another library that happens to implement the X11 APIs on top of Wayland.What's actually underneath this client API (e.g. a "real" X server or just a compatibility shim like XWayland) doesn't really matter, e.g. XWayland is like Proton.
       
 (DIR) Post #B2XlGwOMjQki8wORJQ by floooh@mastodon.gamedev.place
       2026-01-22T10:30:27Z
       
       1 likes, 0 repeats
       
       @shironeko FWIW, I would really like to see a slim standardized window system client library that sits on top of Wayland and provides a more traditional window system API (create/resize/move/close decorated windows, get input events, copy-paste and 3D API glue, but no UI framework).Both KDE and GTK should sit on top of this minimal window system API instead of talking directly to the compositor.E.g. there's a missing abstraction layer in desktop Linux between UI frameworks and compositor.
       
 (DIR) Post #B2XlH3drmCJKd2hPwe by floooh@mastodon.gamedev.place
       2026-01-22T10:38:46Z
       
       0 likes, 0 repeats
       
       @shironeko ...and *if* such a common window system client library exists, then *this* should do the window decoration instead of the compositor. The key is that all UI frameworks (KDE/Qt, GTK, ...) are supposed to use this common client library instead of talking to the compositor. The compositor should be *entirely irrelevant* - not even accessible - for Linux desktop applications, no matter if they use a popular UI framework or do all their rendering via GL or Vulkan.
       
 (DIR) Post #B2XlYgnDT4EOyYTolU by shironeko@fedi.tesaguri.club
       2026-01-22T12:55:35.897230Z
       
       0 likes, 0 repeats
       
       @floooh I thought sokol_app.h is such an api
       
 (DIR) Post #B2XqGqNfa4onGpqBnc by floooh@mastodon.gamedev.place
       2026-01-22T13:31:27Z
       
       1 likes, 0 repeats
       
       @shironeko sokol_app.h is just a cross-platform wrapper around such APIs - similar to GLFW or Rust's winit.Such a new client-library would only make sense when it's a system DLL and guaranteed to be installed on each and every desktop Linux machine.