Re: Clipboard daemon

[Mike Hearn <mike theoretic com>]

On Wed, 29 Oct 2003 10:46:36 +0100, Sir Murray.Cummin scribed thus:
> Also, Mike Hearn sent a mail explaining how the clipboard in Windows
> works. Basically, the old clipboard keeps all data in memory, so it's
> still available after you exit an application. But the new Win32 (OLE)
> clipboard is very similar to the X clipboard: data is only transferred
> when needed, and will be lost if you close the app. He says it's not
> wise to move to a direction that Microsoft is moving away from. ...
> I can't believe that Windows is trying to have the same problem as X in
> future.

I should explain a bit more, clearly. The "new" Win32 OLE clipboard has in
fact been around for many years now, but the "old" clipboard is still in
heavy usage, so their attempts to deprecate it didn't work too well.

> Maybe it's just the big, complex, clipboard formats that get lost.

For instance, try this:

Open up Excel (I think I tested with Office 97, but don't recall), put
some text in some cells, then copy the cells. Go to word, and choose
"Paste Special.." - you should see a list of available formats, including
"MS Excel Spreadsheet" (or whatever), "Rich Text", "Text", and an image
format of some kind, don't recall which.

Hit cancel. Now close Excel, and repeat Paste Special in Word. Now some
but not all of the formats have disappeared - Office is using *both* kinds
of clipboard at once.

There is a key distinction here that you must realise:

* The OLE clipboard on Windows is scoped local to a PROCESS not a WINDOW *

The reason everybody hates the X clipboard is because it's window scoped.
For instance, if I type something into an Evolution mail window, copy it,
create a new message window then try and paste it in, it'll work only as
long as the original window exists. This has bit me several times.

If the clipboard persisted as long as Evolution did, really this would not
be a huge problem.

There are a few other complexities involved - for instance the clipboard
is implemented using DCOM (remoting interfaces into other
processes/threads/machines like Bonobo), which means that if you paste
some complex information into a document as a link, the originating app
will be kept alive through reference counting until the app you pasted
into is quit (or serializes the object into a file and no longer needs the
source running).

> But I think that would be confusing unless there was some dialog saying
> "What you are pasting is not going to be ideal, because you closed the
> other application."

Well, it is confusing.  Until I sat down and did some tests, I would not
have guessed that this is what would happen. Regardless I've used office
suites for many years and never thought about it until now, so I
guess it's confusing only in corner cases.

> Does anyboday have any idea how we can move this issue forward?

Merging Honglis patch into gnome-settings-daemon would be a good first
step. It might not be perfect, but I'd rather increase resource usage than
lose the users work, which unfortunately is a nasty consequence of this
bug. I've lost work because of this before, and it is extremely annoying.

Longer term, it might be worth rethinking the clipboard model, and perhaps
making it independant of X (as really it's not a windowing system feature
at all, it's an application feature).

Final note - clipboard and drag'n'drop are two faces of the same thing in
almost every OS and windowing system. It might be worth trying to unify
them at the user interface level too one day.

thanks -mike