Michael Nagel, I have read carefully your comment and I think you are
right for the non-static data and it might be also complicated to deal
with the history of clipboard managers and this kind of data also...
We could have a history per clipboard type, the text history would
have more items than bitmap type, etc.

But there is some problems with the clipboard manager workaround :

Parcellite -> it is not a Gnome application (does not use gconf, stay
in the notification area, etc) and it is not going to be maintained
anymore (see parcellite website)

Glipper -> dead for three years, and it is written in the mailing list
of the project that it won't be maintained anymore

If we want to have a clipboard manager integrated to distributions,
the first thing to have is maybe a well maintained application for
that first ?

I think we should continue the development of Glipper because it is
written in python and it is easy to patch, maintain and it is also a
real gnome application. Plugins are also very easy to add.

Is someone interesting in making a fork or something about Glipper ?
Once we have a maintained clipboard manager, we could add more
features like the ability to manage different kinds of contents of the
clipboard.

2010/5/24, Michael Nagel <email address hidden>:
> Making the xserver the owner of all content is pretty much the same as
> using a clipboard manager and making that the owner of all content.
> There are working clipboard managers ready to be installed from the
> repository -- namely klipper, glipper and parcellite . they are the more
> or less official workaround as suggested by collin watson (see comment #
> 207 ) why none of these clipboard managers is installed by default goes
> beyond my understanding.
>
> There is one problem with these clipboard manager that causes problems
> with programs like e.g. the gimp and other, that is quite hard to fix
> properly.
>
> When exporting some lines of text to the clipboard the suggested
> approach (just grabbing it when it is exported) will work just fine.
> With binary data like images the problem gets more complicated because
> now you have a lot more data and it potentially contains lots of
> troublesome bits (nullbytes and the like) that must not crash nor
> confuse your clipboard manager. but that is pretty much solved by
> current clipboard mangers, too.
>
> The real problem is about nonstatic data. In the above examples the
> content was present in the source application and you only had to copy
> it away from there. The clipboard offers functionality to create the
> data on demand. For example you could work on some vector graphic in
> inkscape and copy and paste the data to gimp where it would arrive as
> pixel data. The pixel data is only created when you paste it somewhere.
> So you can copy a hundred times and paste only the last copy, then only
> that version will be converted to pixel data. That is the clipboard
> basically asks your application to provide some content and it is up to
> you if you answer with some existing data or generate some new data just
> to satisfy that request. When that generation is expensive it is not
> practicable to do it every time something is offered to the clipboard
> but only when something is requested from the clipboard. But a clipboard
> manager basically request the data every time some data is offered to
> the clipboard invalidating that optimization and causing a lot of data
> to be generated and transferred.
>
> That overhead might be tolerated, too. But to further complicate matters:
> When exporting something to the clipboard you don't export something fixed.
> Fixed means you already decided about what to export (although you might not
> yet have created it yet -- see above). No, you say that you offer "plain
> text",  "rich text", "binary data" or "a nice picture". When pasting the
> application does not request the "contents of the clipboard" but says it
> understands "plain text", "vector graphics", "binary data" and "wave
> sounds". Now some arbitration takes place and the applications agree on
> transferring "plain text" (or "binary data" whatever is better for some
> definition of better). Thus it is not even clear what a clipboard manager
> should grab when an application offers some data for export to the
> clipboard. It might grab all the offered datastreams but that obviously
> means some heavy overhead...
>
> One thing gnome does is to offer a clipboard manager where your
> application can store the things it offers to the clipboard when it
> exits. Control over the clipboard is then transferred to that clipboard
> manager. That way no data is lost and data is only copied when your
> application exits, minimizing overhead. This means each and every past,
> present and future application must be extended to make use of that
> manager (opt in instead of opt out or forced use of the manager). That
> is not gonna happen. Furthermore it will not work for crashing
> applications...
>
> Conclusion: Why not go with a clipboard manager that grabs everything?
> And then working around the performance bottlenecks by stopping certain
> transfers from happening? You could offer an API to application to mark
> certain exports as not relevant for the clipboard manager and you could
> blacklist certain offerings in the clipboard manager for some cases
> where you cannot modify the application. You could even display a shiny
> notify-system message telling the user: "what you just copied will not
> be available permanently. Paste it now before closing that app!" That
> manager would support legacy applcation and should be installed by
> default so no user is bothered with this bug ever again.
>
> How to implement: Patch glipper/parcellite to grab everything, offer
> some blacklisting to mitigate bottlenecks and talk to someone at
> canonical to include it in the default install...
>
> --
> MASTER Copy-Paste doesn't work if the source is closed before the paste
> https://bugs.launchpad.net/bugs/11334
> You received this bug notification because you are a direct subscriber
> of the bug.
>