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

[Jerry Haltom <jhaltom feedbackplusinc com>]

Additional answers:

> It's a nice idea, and may well be doable, but I'm concerned this could
> lead to a lot of subtle bugs. You say that "most of the app would
> be unloaded anyway", but I don't think that's true.  In order to perform
> format conversion for most apps I can think of they'd need to keep the
> majority of the app in memory, unless they did it ahead of time (in which
> case you might as well just use an escrow daemon and shared memory).

I am also concerned about subtle bugs. A lot of thought would have to be
given to how to properly implement a "half-shutdown" procedure. Mostly
thought at the toolkit level I believe.

> In particular, if a toolkit was adapted to mostly but not actually quit
> when holding the selection, I can see all kinds of evil crashes caused by
> apps using resources that were already freed. Suspending an apps shutdown
> then running arbitrary codepaths is not a change to be taken lightly.

This would not be an automatic change. Another poster (Soeren Sandmaan),
suggested a new gtk_main_quit() function... and I agree. Something such
as gtk_main_quit_interactive(), which would destroy all interactive UI
components of the application. A GTK application would have to
explicitly implement this, until which time copy/paste would work as it
does currently.

> As already mentioned this also leads to wierd semantics with single
> instance apps and stuff ... definitely scary :)

A clipboard daemon can still be implemented with this plan, as long as
the data type is text/plain, for instance. For more complex data types,
the program would simply have to be modified.

This means proper copy/paste policy becomes a function of the individual
application, just like the HIG.

-- 
Jerry Haltom
Feedback Plus, Inc.