Rethinking the GNOME clipboard issues
8 points by edu4rdshl
8 points by edu4rdshl
I have used several clipboard managers on GNOME over the years, and they all eventually did the same thing: the desktop would hitch.
KDE has this too. Especially severe, long freezes on CTRL+C when you use Wine applications. It's super annoying and it makes the entire desktop environment feel so much less polished than it is otherwise.
Why is it that decades after BeOS, most GUI frameworks are still inherently single-threaded?
First, for the same reason Win32 is such an awkward API... backwards compatibility with existing developer mental models. (The elements of Win16 that predate virtual memory in that case... so we're talking about the support for running on 8086/8088 CPUs in Real Mode which was dropped when Windows 3.1 bumped the system requirement to an 80286 and an API also designed when RAM prices made the A.I. bubble blush.)
Qt traces back to 1991 and GTK is only 3 years younger than BeOS (1998 vs. 1995) and was informed by other toolkits of the time.
Second, because C and C++ make concurrency so difficult to get right that, even if you're not trying to completely rework an existing API without the help of a borrow checker, it's still something people have a low-level aversion to.
(For my own work, where I moved from PyGTK and GTK+ 2.x to PyQt5 and beyond so I would have to reinvent fewer APIs in each project, I use a QThreadPool and QRunnables to chase what macOS users get with Grand Central Dispatch, NSOperation, and NSOperationQueue, but even macOS is still fundamentally an "on main thready by default" platform from what I remember. I think the justification was that if you go to the opposite extreme and make all event handlers run on a background thread by default, that also introduces noticeable latency in the GUI response and it's a much more pervasive "my UI is written with webtech!" sort of problem.)
TBH, I actually like to have a single-threaded event loop. But there needs to be a nice way to spawn side threads (both long-lived and short-lived) and return their results back to the main thread. That way you get deterministic event ordering by default, but if you have long-running operations you can decide to move them off the main thread.
In the end this clipboard manager works by the same principle, but it uses DBus and a separate process (rather than threading) to handle long-running tasks.
Not just that, why is it that the lesson "don't block the GUI thread" has to be relearned all day every day for decades already? The current paradigm doesn't work. Really makes you want to design a language that gives each GUI operation a limited budget and just moves on when the budget is spent. Kind of like a borrow checker but to check and reject blocking behavior.