Reading how copy-paste works from the Wayland specification is non-trivial unless you understand a lot of how desktop computing works and Wayland internal. It took me quite a while to figure it all out, though once you get there, it seems quite obvious.
Here’s my attempt at explaining how it works for mere mortals.
One of those things you do countless times every day, but don’t really know how it works.
Hm, no pasting after an app is closed? That’s a bummer, and pretty sure doesn’t affect other platforms to the same degree.
If this truly is just a Linux issue, how does copy-paste on other platforms handle it then?
It works in KDE. We have the klipper to keep the clipboard content alive after an application closes.
That probably explains the early cut/paste wayland bugs I used to get with KDE.
Yes, users love it, but autotests hate it..
Moochman,
I’ve tested the linux clipboard behavior with a few apps like libreoffice, kate, gimp, konsole under X11 (haven’t tested wayland). Copies that include text do outlast the application lifetime. However formatted versions of text and images only last so long as the source application is open. I’m not really sure how long they’ll keep the clipboard resources active. I found that copying something in LO writer and closing it while LO calc is running kept the clipboard intact until they’re both closed. I guess they may be doing something special to support this in LibreOffice.
This all reminds me of DDE in windows as a means of transffering data in realtime. There was OLE too. I thought these were awesome when I learned about them, but outside of microsoft application support was kind of limited & niche. Still it was a cool way to cross the app barrier and automate stuff! I haven’t found a similarly easy way to automate linux GUI apps.
Alfman,
I’m not sure we’ll be seeing good desktop testing soon. We can argue automation also opens up doors to backdoors.
That being said, isn’t D-BUS is supposed to handle what DDE did in Windows? In other words: calling RPCs in UI applications?
https://www.techrepublic.com/article/a-quick-presentation-of-d-bus-based-automation/
(To be honest, never programmed it myself).
sukru,
Well, originally every application had root access anyways, so local software could just take the front door instead of a “backdoor”. In modern and network incarnations I think that DDE only works within a user’s own access domain and is “protected” with prompts on top of that. I looked it up and this link says it was disabled by default in word but continues in excel and outlook.
https://www.bleepingcomputer.com/news/microsoft/microsoft-disables-dde-feature-in-word-to-prevent-further-malware-attacks/
I’m ok with it being disabled by default, people who need it can enable it for themselves.
I guess that could work. While it would be possible to build an automation layer over DBUS, I usually think of D-BUS as a way for programmers to implement low level IPC rather than user focused automation. Now that you’ve mentioned it though it makes me wonder if there are applications using it for full application automation? I have no idea. The problem with this approach is that it’s not portable, but then neither was DDE.
I’ve automated browsers, but they use a different interface.
https://www.selenium.dev/documentation/
Alfman,
Yes, selenium made a whole new set of tools possible.
But, the web has a structured DOM, and very structured event processing. Modern desktops on the other hand moving to ad hoc composition, and “parsing” a random window could require OCR or similar techniques.
As far as I remember, Win32 used to have a separate windows ID for each and every control on the screen. So one could iterate: “this is the app main window”, “this is the tab page on it”, “this is the SUBMIT button on that page”, etc. Today in WPF/UWP it could be a canvas image.
And this effects accessibility negatively as well. And TAB navigation of course.
sukru,
That’s why I wanted to highlight the browser’s automation capabilities, it’s really quite powerful. Although they’re not technically related, browser automation would be a worthy successor to DDE. 🙂
It depends on the framework, but on the whole I think things have gotten more complicated for automation of generic apps. Even wayland’s API limitations makes thins more complicated than win32 and X11 and might have to make a separate implementation for every desktop compositor.
Minor update:
Turns out it is possible to do UI automation for WPF programs. However that seems to require selective support from the app itself:
https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/march/test-run-automating-ui-tests-in-wpf-applications
Basically the developer chooses which controls can be accessed by assigning them an id.
Problem loading page
Secure Connection Failed
An error occurred during a connection to whynothugo.nl.
https://whynothugo.nl/journal/2022/10/21/how-the-clipboard-works/
🙁
Same 🙁
The site is up again 🙂
What a broken design. Once something is copied to the clipboard, the user should be free to close the application. Another reason to avoid Linux.
No this is a tricky one. If you have a clipboard manager under Linux you close application the data can remain because of the clipboard manager. So you can have data remain after the application is closed.
Its also possible that the clipboard manager can be selective on what applications get access to the data put on clipboard. Some cases with security you want the application to check what other applications it letting get copies of clipboard contents. Yes secure desktop setups most don’t think of.
The reality is depending on the need of the user alters how the preserve clipboard should behave. Valid options are.
1) application while running in charge of what applications can copy clipboard from it and the clipboard contents will disappear when application closes.
2) application can close and something else in the system preserves the clipboard contents after the application closes.
3) Application can close and something else preserve the clipboard contents but adds a security framework on where the clipboard contents can go.
You need to be able to implement all 3 to cover all clipboard use cases.
Wow, got off wrong right from the start. The clipboard and the selection are two different buffers, working differently..