Re: Follow up about X clipboard

[Pat Suwalski <pat suwalski net>]

I'll keep it short-ish...

Jerry Haltom wrote:
> 1. Non-deterministic shutdown of applications is confusing.
>
> The basis for this argument is that when a user closes the last window
> of an application, they expect that process to terminate... as in no
> longer be running. The main problem I see with this argument is that
> users today have absolutely no concept of what a "process" is anyways.

I disagree. I would say that easily 75% of windows users know what a 
process is. Not necessarily by name, maybe by "that thing I have to kill 
in the task manager." There will be regular users who use the gnome 
system monitor and wonder why the program is still running.

> 2. Non-deterministic shutdown leaves possibly broken applications
> running with no option in the GUI to terminate them.
>
> Good one! After an application closes all it's windows, and frees all
> memory required for them (or whatever), it enters a sort of daemon
> state, where it keeps running until it no longer owns the clipboard.

I still think it's unreasonable to keep the process going. I see a 
better solution as passing off responsibility to the clipd and making 
translators smart enough to know how to handle that, what to do. 
Something that leaves absolutely no doubt that the copying program was 
closed.

> 3. Some applications are big. It makes no sense to keep them running in
> the background forever.
>
> Yes it does. The user has indicated he WANTS to copy (make available
> later) a certain amount of data. This means the system is obligated to
> either not offer him this feature, or preserve the data in some fashion.

This is just plain wrong. If I mean to hit Ctrl-F to search, and 
accidentally hit Ctrl-C, I don't want that program there. Also, what if 
I copy from this program, paste into another, then close the copying 
program? Why the hell should it stay running in RAM?

> 4. Why don't we just inform the user the clipboard or an amount of
> clipboard data will be lost when he closes a window?
>
> This is directly involving the user in a decision involving a deficiency
> in the implementation. The user does not know what "data types" are. The

I disagree with this wholehartedly. Not only is it extremely clean on 
the back-end of things, but it keeps the user informed. There is no 
shame in saying that if you close this app from which you copied, you 
will not be able to paste into other apps. There are just so many 
programs that do that across all platforms. And it makes sense to any 
user who gives it half-a-thought. "I closed this window, so where will 
my computer keep my copy? I hope it's not on the internet where it could 
pick up a virus..."

> 6. Long running applications with a non-deterministic shutdown provide
> more points for fault.
>
> Of course. Any ability we add to anything provides a fault point. I'd
> like to believe, based on the other points 1-5 mentioned above, that
> such fault points are not as disastrous as they are made out to be.

It's been brought up. Yes, it matters. Say the process is eating 99% 
CPU. This is consistent behaviour from soemthing like Adobe's Acrobat 
Viewer. The last thing I want with this program is that it disappears 
into a spot where I can't easily close it from. That so totally 
overrules extended clipboard functionality.

> 8. Why not implement some sort of Clipboard Daemon (clipd) which has the
> logic available to it, either through plug-ins or natively to transform
> the data from one type to another.
>
> Consideration of the size of future/present data sets. Linux/Unix today
> doesn't have any good examples of widespread software such as
> audio/movie editing. However, the ability for this type of data to work
> with the system must be addressed. This type of data is generally LARGE.

Again, here's my POV on this. If there's a session-wide clipd, to which 
a program can hand (1) its copied data (by reference, until killed), (2) 
a group of translators, and then the main program can die, that seems 
like a good solution. Magic would still have to happen with large files.

> 9. Translator framework like BeOS?
>
> I don't know enough about this idea to really totally understand it...
> but I will try.

This is the coolest thing I've heard here so far. It doesn't even need a 
whole new clipboard semantic. This would be cool to have with the 
existing clipboard if implemented somewhere between the GTK and X levels.

My four cents.
--Pat