Category Archives: Computers

I got the upgrade to GIMP 3.0 yesterday, went to do a few basic image editing tasks, and it’s great they’ve fixed many of their long-standing issues and added things like NDE for filters, wider color depth, etc. … but I was so annoyed by the dialog-buttons-in-title-bar situation caused by the move to GTK3 that I stopped what I was doing and looked for a workaround.

Dialog-buttons-on-top is backwards from reading order, backwards from every other piece of software I use, and backwards from almost every other piece of software made in the last 40 years – I’m not interested in arguing if the GTK folks repeatedly doubling down on their weird bullshit is legitimate, I just want to be rid of it.

It turns out there isn’t really a runtime workaround on Wayland, your choices are force it to use the X back-end via `GDK_BACKEND=x11 gimp` so it will respect the gtk-dialogs-use-header=FALSE setting, or patch and rebuild GTK3. Because that setting gets overridden with the Wayland back-end. Unless you delete like 4 lines of code and rebuild the whole library, since the “technical reason” it had to be hard-coded for wayland is apparently just some bad behavior with CSD bars (which are also undesired behavior – I want consistent window controls and labels plumbed by my environment) that come up when running under gnome.

…And since you’re replacing your system gtk3 with a rebuilt library anyway, there’s gtk3-classic. Which isn’t packaged, so you have to build locally. From some random github repo and an AUR package. But it is pre-patched, and gets rid of a bunch of the other misfeatures like the search-instead-of-typeahead and some weird CSDisms at the same time.

I moved from daily driving xfce to kde in like 2017 because GTK3 was awful (and the KDE folks got their resource usage in check), and the stragglers (gimp, inkscape) moving to gtk3 is making me think about it again, because it is now even more awful. At least GTK3 is basically frozen at this point, so I won’t have to build the replacement too often.

I was having Vulkan/Wine interaction issues when I had a minute to play a game the other night and flipped my big laptop (which has Intel/AMD Polaris12 dual graphics, both running the Mesa stack since AMD dropped Polaris support in amdvlk in the 2023.Q4 release) into a Plasma Wayland session (v5.27) to see if it helped. It did – making it the very first thing I’ve encountered that worked in Wayland and not X – so I’m rolling with the Plasma Wayland session for a couple days to see how things are. I have a little machine I’ve been playing with Hyprland on to check out the Wayland situation, and it’s been closing from “Linux 20 years ago” to “Linux 5 years ago” in terms of brokenness, so it seems plausible that one of the big two would be tolerable now.

I’m totally onboard that xf86->xorg is an unmaintainable mess for both legacy-codebase and design from a different era reasons, and it would be nice to start with something built on assumptions that match modern reality, but uh… over a decade in, Wayland is just getting to be less of a “almost a tech demo” and more of an “almost there.” If the devs can shut up about some bikeshedding that obstructs common use cases now over concerns about theoretical security issues or compatibility with yet-unimagined future interface models and implement widely-accepted solutions to the last few basic-fucking-features, it might actually matter before it too starts to exhibit wrong ancient assumptions and gets replaced, but it looks like they’ve missed the bus on a couple of those necessary standardizations.

Things I use regularly that are currently broken in KDE’s Plasma Wayland session in Nov. 2023:

• The mere fact that I have to specify it’s a KDE Plasma session for all these details because every compositor is having to reinvent a bunch of wheels in differently-broken ways – input plumbing, session management, etc. They could have at least spun some reference libraries and treated anyone who didn’t use them when building desktop-like interfaces as a second class citizen to paper over the necessary parts to build a desktop they didn’t want in the core protocol (and for some of them someone else did it; see PipeWire). Wayland’s entire development process is built around former X devs being exceptionally gunshy about maintenance and attempting to avoid having any meaningful implementation under their auspices, and it’s causing a lot of goofy decisions. wlroots was too little too late.
• KeepassXC can’t do its autotype into last active window thing.
  • Relevant Bug
  • Because Wayland completely abdicated on input plumbing and programmatic window selection. It even sort-of works between xwayland windows because X is a feature-complete desktop protocol and Wayland isn’t.
  • I use this ALL THE TIME and it drives me CRAZY. Browser extensions are not a comparable solution, I auto-type credentials into all kinds of windows.
  • They finally accepted ext-foreign-toplevel-list so the plumbing for window selection is theoretically there… but I don’t think any compositors implement it yet.
  • The pipe-input-to-a-specifc-window shit is still being bikeshedded over mostly-irrelevant security concerns. Maybe maybe the ever-contended global hotkeys stuff in xdg-destop-portal will make it possible, but since every compositor has sprung a bespoke portal variant, even that may not comprise a global solution, and it’s not entirely clear it’ll work for piping arbitrary strings anyway.
• Everything restores to a random virtual desktop, if it restores at all.
  • KDE Bug for sessionrestore and also xwayland session restore
  • I think only the xwayland windows are restoring because, refrain, X11+extensions is actually a complete desktop protocol and Wayland still isn’t.
  • There’s no generic solution, and gnome spun their own internal bullshit which seems to be further sandbagging a general solution.
  • KDE is thus also spinning their own internal bullshit, so everything will be broken forever.
  • This is like basic 90s shit being fundamentally bobbled.
• Firefox PiP windows
  • The wayland devs are still busy insisting the use case supported on every major windowing system including the coercive prisons like iOS and Android for years is wrong
  • They might be right that it shouldn’t be a specific feature, there should probably be more layers exposed than there are in general. The interaction of always-on-top and things like trays and bars is also janky I just don’t run into it quite as often.
  • Ed: …and sometimes it now not only works but shows the control I was having trouble with in the next point when right clicked.
• The “Move to Screen” context menu item in the task switcher seems to have vanished? I can still do “Move” and scoot a program to the desired monitor and it seems to snap correctly, but sometimes fullscreen windows relocated that way jump back to the first display. Apparently it has never been available from the task manager, only the title bar right-click menu and my memory is faulty.
• I don’t know if it’s Wayland related, but baloo has started acting up again. I’m regularly seeing baloo_file_extractor eating a whole core when it hits things like openembedded trees. It’s possible I just disabled it in my saved X session and it’s being started again because the session management carryover between X and Wayland Plasma sessions is half-working.

The whole situation is silly. It’s a gigantic shell-game of trying to outsource the solutions to problems everyone already knew needed to be solved consistently because the ICCM and EWMH stuff for X represented decades of effort to do so, by the people best situated to actually solve the problems at the time when they could be solved in a general way.

I sometimes get the feeling reading the bug trackers that many of the Wayland people are building a display layer suitable for infotainment systems, kiosks, signage, and that sort of thing, and desktop functionality is an unfortunate extra thing some people are trying to force on them – which, financially, may be the case.