New clipboard proposal

[Philip Van Hoof]

On Fri, 2004-12-31 at 18:05 +0100, Kevin Krammer wrote:
> On Thursday 30 December 2004 20:21, Philip Van Hoof wrote:
> 
> > o. A clipboard manager will, using the new Xfixes extensions,
> >    catch clipboards that will be lost if the selection-owner
> >    gets destroyed. That same clipboard manager will persist
> >    the clipboard when the session is about to get shutdown.

> I think this is a problem.
> Imagine you have an application and the selection is about 100MB of data.
> As long as the owner exists and no transfer is requested this 100MB of data 
> are part of the application's memory space.

Indeed. And it's important to know about this. So your concerns are
indeed important issues which I will address ..

> When the application exits the manager either has to "choose" one target or, 
> as I read in some other reply, request all targets.

> First option has the problem that pasting while the owner is still present 
> will very likely get you a different result than pasting from the manager, 
> while the second option has the problem that it will multiply the amount of 
> necessary memory by the number of targets.

Well, not necessarily. I've noticed this problem (a long time ago while
maintaining "gcm"). My solution to the problem is to persist such
clipboard-data on disk only. Not to put it in allocated memory (or to
free it right after it's been written to disk). Delivery of the
clipboard should be fast. Trying to make it faster than reading from a
disk would be nice, but I don't see it as a goal. Especially not for
clipboards that had to be rescued by a manager.

This will need, indeed, a variable but certain amount of diskspace in
case a clipboard-owner dies. But there's no other way I fear. In case a
plugin that would make clipboard histories possible is going to be
build, it would be a good solution to do the same thing (not storing all
those clipboards in memory but in stead only storing them on disk).

Applications can use an internal memory-buffer using an internal
formatting of their clipboard, and convert it to the requested format
"on-request". A clipboard manager who's going to rescue such a clipboard
can't know about that logic. Letting the clipboard-owner give it's
original format wouldn't be useful either, since the manager doesn't
know how to convert it to the possible formats (unless there's some
common macro language available which can be fed with such an original
and a parameter for the target format -- but such a language isn't used
nor available --).



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org