[Development] Hacking fun with the XCB QPA plugin (on retro set-ups)
René J.V. Bertin
rjvbertin at gmail.com
Fri Aug 7 22:51:23 CEST 2026
Hi!
(cross-posted from the interest ML at Thiago Maciera's suggestion)
I'm very much into retro-computing these days - I find it much more rewarding to keep a well-groomed and customised OS version up-to-date with self-built crucial components than upgrading to the latest-and-supposedly-greatest (and continuously spending time figuring out how to get things to work/look the way I expect rather than what the latest batch of young bloods think is best).
Anyway, among the components that I have been keeping functional against newer dependencies is Qt 5.9 (mostly because it's the last version I can run on my old Mac).
Among its few annoying habits is the fact that under X11 it will lose "copy-to-clipboard" functionality from time to time. Usually that happens in all running applications at the same time, so it must be some "global" event in the X server. I observe it mostly under Mac OS X (yes, I figured out how to do an X11 build there) but it does happen occasionally on Linux, too. When this happens, new content can only be copied to the clipboard from unaffected applications; pasting continues to work.
On Linux I also use Qt 5.12 for some applications, and I noticed it appears to have a somewhat different implementation of the clipboard functionality and thought I'd try to build its XCB QPA plugin as a standalone alternative plugin for Qt 5.9 .
https://github.com/RJVB/QAltXcbQPA
Took me a few days but it was mostly of the "tedious but trivial" kind of porting effort.
The result works but still has a glitch where windows are opened at an upward shifted position, by approximately the titlebar height. That includes menus attached to the menubar (but not submenus or contextmenus). Info popups can also have a considerable horizontal offset (e.g. in Dolphin).
I know this is old-if-not-ancient code for many of you, but does either issue ring a bell?
* what's the deal with the clipboard issue? Fixing it in 5.9 would be preferable, of course.
* what could cause the position offset? Was something moved from a standard component library into the plugin that is now being applied twice, for instance?
Thanks!
René
More information about the Development
mailing list