Re: Follow up about X clipboard

[Jerry Haltom <wasabi larvalstage net>]

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

I would say that 90% of those 75% only know what a process is because of
a deficiency in Windows of some sort requiring them to deal with a
process as a process, such as a freeze. This isn't something we should
accept and say if it's good enough for Microsoft it's good enough for
us. Does OS X even have a system monitor?

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

I still don't understand why. What is so bad about long running
processes that me or somebody else hasn't already explained? Is it just
a "design/moral/ethical" argument? You can never win those.

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

That's why I suggested a notification area icon (or something) to let
the user (those that care that they are using memory, most people will
just not care at all) that would allow the user to clear the clipboard.
Actually this is probably a good idea in any clipboard design to allow
users to remove copied passwords/sensitive data.

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

This argument doesn't really hold any weight. If the user wants to copy
from Adobe Acrobat, then for the duration of that copy, they must leave
Adobe Acrobat open, eating 99% CPU, RIGHT NOW. If the user later decides
they don't want to make a copy, they can clear the clipboard in some
fashion.

Either way, this program needs to be fixed. This is retarded. I've seen
it too. If Adobe spends the time to make it long living, they can spend
a few minutes of that to fix this problem. If they don't, then this
application is not worth using in any way.

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

Okay. I think we can agree on this. A clipd is not a bad approach in all
situations. In fact I would say a clipd/hybrid what I said concept is
the best. Consider:

A clipd is written that is programmed to capture many common file types.
It needs no knowledge of what these types are... just a list of them.
Some of these are text/plain, text/xml, image/png, image/jpeg. Common
formats which WE recognize are used all the time, and are simply and
small to cache.

When the clipd sees that a program has one of these types available for
copy, it requests it from the owning program, and stores it in memory.
The clipd then requests ownership of the clipboard. This means the clipd
doesn't need any logic about how a file type works... no conversion. It
simply needs a list of types and sizes/constraints that it should cache.
Applications are not aware of it.

However, if the application advertises 1 types that clipd supports, and
1 type it does not, clipd MUST NOT attempt to cache any of them.
Additionally, if an application advertises 2 types, it should not
attempt to cache either. Generating formats that will never be used
isn't really good practice.

This leaves clipd free to cache text/plain, and lots of single image
types, relieving those applications (a large category) from needing to
stay active in the background.

This does not mean however that it relieves all applications.

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

I agree. This is a totally cool idea we should implement anyways.

-- 
Jerry Haltom <wasabi larvalstage net>

Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html