Comment 234 for bug 11334

The most complicated part of the issue described here is following:

"Only application knows how to handle its buffer properly, hence when it's closed - nobody can paste it."

The example can be quite simple: you enter formatted text, pictures and tables in OOo' Writer and then select-all and paste it to:
* notepad app (like gedit/kate/gvim/...) - only text is pasted
* bitmap editor (like gpaint/kpaint/...) - the whole buffer is represented as picture and pasted on the canvas
* another OOo' Writer window - the original formatting is kept (tables are tables, text is text, pictures are pictures...)

Everything is handled by OOo' itself. No clipboard manager will ever be able to the same work after OOo is closed.
... And it's not needed! Why reinvent the wheel?!

This is my idea on how to implement it properly:

"Take the code that handles the buffer off the application (like OOo and others), and place it into the X-server. As a plugin.
When OOo is closed, it's plugin is still present and works with X-server to process 'paste'-requests."

PS. OOo is just an example, take any other complex app, like dia/gimp/firefox/... instead if you wish.

pros/cons:
+ such a plugin is developed by developers of the original app and not by bystanders: less time to deliver the working plugin than adding support of strange source-buffer-type to clipboard manager
+ the plugin is no more than just a replacement of "paste"-handler from within the app to the X-server
+ no need to maintain "clipboard managers" for each DE
+ it's not a band-aid solution: it works on all permutations of "source"/"target" type pairs
+ some plugins may support more than one "source" applications (no need to write different plugins for simple notepad-applications, the same - for all simple raster graphic editors)
- need to create a clear spec and ask developers to follow it

Isn't it a good idea? :)