[Annoyances] X-Windows Copy & Paste

[Mike Hearn]

On Thu, 2003-08-21 at 15:19, Thomas Leonard wrote:
> Why not just use the MIME types, as we do for drag-and-drop (which works
> just like the clipboard anyway)?
> (image/png, application/octet-stream for your examples)

Well, for files I actually was thinking of URIs. For instance if you
drag a file from nautilus and konqueror, you get different URIs.

Yeah, the work isn't hard, somebody just needs to sit down and say "for
copy and paste of images, we will use PNG", and "for copy and paste of
colours, we will use #aabbcc notation" or whatever, and then get people
to use it.

> > It might be worth considering (timidly) dropping X selections for the
> > clipboard entirely at some point, and moving to an separate system that
> > works how you might expect off the bat, and is capable of doing all the
> > whizzy types people expect, doesn't suffer wierd problems with >64k of
> > data etc.
> 
> What wierd problems? Don't the toolkits deal with this for us?

I was thinking of issues Mozilla has here. Yes, it's a toolkit issue,
some oddity with the X protocol and timing, but if you think how many
toolkits are on the desktop these days, avoiding these issues in the
first place seems wise.

> The only problem with the clipboard, as I understand it, is that if you
> quit the application then you lose the clipboard. But that's not a
> technical issue... it's just that we genuinely don't know if the user's
> going to use the clipboard again. We could easily prevent an application
> from quitting while it owns the clipboard if we wanted.

Better to make the clipboard work the way it does in Windows, and simply
have it persistant.

The main problems with the clipboard IMHO are:

- The brokenness we already covered WRT non-text
- The fact that it works differently to windows in terms of persistance
- It's a rather confusing thing to understand. You have to remember
what's in the clipboard at all times. Windows used to have a clipboard
viewer app, I don't know if it still does, but there is usually little
to no visual indication of when you copied something, what was copied,
what it replaced etc. It's a rather abstract concept.
- It doesn't persist *anywhere*, meaning that if you cut something to
the clipboard intending to paste it later and you have a power cut, it's
gone.
- The "clipboard" metaphor artificially restricts it to only being able
to hold one item, something that is now hard coded into the
implementation. You could argue that allowing more items would lead to
an UI nightmare, but I think you could come up with something workable.

I sometimes wonder if a better approach would not be to use drag and
drop more, so rather than copy/paste you drag pieces of text, images,
files etc to a space on the panel (think something like the MacOS dock
which scales the icons as you drop things in). That applet would hold
onto these bits of data, transparently save them so they are there when
you next log in, allow you to view what's in the clipboard etc. Dragging
them out again copies them, dragging them to the trash can deletes them?

Well, I'll let you use your imagination for the rest, I think it's
obvious where I'm going.

That's why I said it'd be more a research project - Windows users (ie
everybody) are used to cut/copy/paste, and it's firmly entrenched now
for better or worse, so other systems to do the same thing should have
low priority.