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

[Jerry Haltom <jhaltom feedbackplusinc com>]

> 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.

That's a very good point and one of the cons against long lived programs
I didn't consider. We have to play it careful when we talk about
"working around" applications that CRASH. Crashing needs to be fixed.
Under no normal circumstances should an application just bail on the
user. However, the system has to be robust enough that a single
application does not bring the system to it's knees.

A few options are to not inform the user when a "sleeping" application
crashes. He doesn't REALLY need to know anyways. It has no open UI
elements, and the only effect will be the loss of the clipboard.
Alternatively, does it matter? A program crashing should be a rare
event, and if it isn't it needs to be. Also, the chances of a user
keeping a piece of clipboard data around for more than a few minutes is
slim. It won't happen much. The user will see the Crash dialog usually
very shortly after they do the actual copy. In other cases, does it
matter?

> 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?

My general opinion is that the user should never be prompted for
information regarding the clipboard unless it is an action he directly
caused by using the clipboard (such as pasting, or copying). Delaying a
message relating to the clipboard until application close will confuse
the user. He may not even be aware there is something useful on the
clipboard. Additionally, the user need not be aware of the
implementation details of our clipboard... that it loses data. He won't
even know what that means. In my situation, it would prompt a help desk
call.

-- 
Jerry Haltom
Feedback Plus, Inc.