Re: State of the X clipboard, and perhaps a solution

[Alan <alan ufies org>]

[snip]
> This idea however makes program shutdown non-deterministic. A user
> cannot be assured that just because he told the program to exits, that
> the real underlying process has in fact exited. I would weight this
> against the benefits of having a really nice fully featured Just Works
> clipboard however. Also, is this really a problem? A user isn't suppose
> to have knowledge about how a process is implemented... he isn't suppose
> to care that a program hangs around in the background when he thinks
> it's closed, likely no user will ever even notice nor care. Worth
> considering is that only one of these sleeping processes will every
> exist at a time (barring implementation of multiple clipboards).
> 
> Anyhow, discuss. I want to hear pros/cons, etc. This proposal doesn't
> require any new specifications of interprocess communication at all,
> simply a modification to the life-cycle of a program... which is handled
> by libraries such as GTK and QT.

A couple of thoughts on this... 

I can see a bit of confusion with the idea of the apps not shutting
down.  This could confuse end users and I see potential problems if
something is buggy, or what have you.  Also, if I understand what you
described, data from the clipboard will be lost when the app no longer
owns the clipboard, which means that the data will be available until
some other app copies data.  This means that (potentially) in the case
of a buggy app I can copy data from fooApp, then an hour later copy
data from barApp and suddenly get a crash message from fooApp, which I
as a user shut down long ago.  If this was all done in gtk and didn't
require application developers to do much (if any) work though the risks
could be mitagated.  

I'm sure it's been discussed before, in one of the many 'lets fix the
clipboard' threads, but could this idea be integrated somehow with the
idea of an escrow which will accept a copy of N megs of X type data, 
after which if an application quits it will inform the user that there's 
data in the clipboard that will be lost unless they click yes to keep
it, like some windows apps do for copied data that doesn't match up with
whatever internal OLE/COM methods are used for copying data?  Could
therer be two solutions, one small escrow daemon for small and simple
data (ie: < 1m of text/rtf)?  It would seem a bit silly to have gedit
sticking around just because I hit ^c to copy a word or two.  Maybe
bring back the gnome clipboard daemon in it's simple form for this?

Just putting in my $0.02 here.... I'm glad that this was brought up
again though, as it still makes me sad that it's 2004 and this is
*still* an issue on linux, and it wasn't ever (IIRC) an issue on other
platforms :(  Of course, it also makes me sad I don't have the skills to
help solve the problem.

Best regards,

alan

-- 
Alan <alan ufies org> - http://arcterex.net
--------------------------------------------------------------------
"There are only 3 real sports: bull-fighting, car racing and mountain 
climbing. All the others are mere games."                -- Hemingway