The SAVE_TARGETS Atom

Hey Sven,

A few days ago I tested the clipboard-manager of Anders. Regretfully, however, it’s using gtk. It would be better if a desktop-neutral solution was build. The freedesktop concept really doesn’t need ten different solutions for one little problem. No I don’t hate gtk. But lets be reasonable and accept the fact that not everybody likes depending on gtk. We can always conqueror the world later.

And the clipboard-manager only fixes one issue and only for applications that can and will be modified. Many applications will not be modified and will therefore still cause the clipboard to disappear when they owned it and decided to shut down. So the backwards compatibility issue isn’t fully resolved. Yet I agree it’s a nice solution: In my document I wrote that (imho) it’s not always a good idea to overcommit yourself to backwards compatibility. In the end it needs to solve the problems. A long-term solution would be to create a series of standard target-formats (xslt?) and to let those persist automatically (by a clipboard manager). The current solution requires that the desktop application developer understands a specific detail of the clipboard system: The fact that a clipboard manager needs notification of which targets to persist. Whereas that should be obvious for certain formats! Desktop application developers shouldn’t have to worry about such specifics (and in reality I think they’ll often disregard it).

Perhaps a solution for xclients that don’t have “persistent targets” (is it the “SAVE_TARGETS” atom? The document you talked about isn’t available on fdo) could be to nevertheless save (one of) the UTF-8 plaintext targets.

And it’s not the only problem of the X11 clipboard. There’s many other problems like the performance on remote xserver X11 deployments, support for console applications, recovery after session restart, etcetera.