[Annoyances] X-Windows Copy & Paste

[Lubos Lunak]

On Thursday 21 of August 2003 16:35, Mike Hearn wrote:
> 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.

 Why not simply doing it the way it is now, and keeping saying 'for copy and 
paste of images, we will use images', and 'for copy and paste of colours, we 
will use whatever mimetype there is for this, and if there isn't, we'll 
create one' ? No need to try to make this complicated. There are already 
mimetypes and their formats defined for many things, and when more are 
needed, they can be added (and standardized upon). BTW, if the nautilus vs 
konqueror case is file:/ vs file:///, then those are both valid URIs (at 
least according to those KDE developers who wrote the code, I don't feel like 
searching in the RFCs).

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

 So we replace X selections with something different, and we'll get different 
problems. Great victory.

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

 Can be fixed e.g. by using Klipper (or whichever xclipboard-like tool), at 
the expense of some X bandwith (which would be there anyway, for any kind of 
making it persistent). When the bandwith available is low, it can be however 
easily fixed by not running Klipper.

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

 Solved by Klipper as well.

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

 Solved by Klipper as well.

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

 Solved by Klipper as well.

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

 Drag&drop is almost the same like copy&paste from the technical point of 
view. You're not going to win anything, at most getting a different and 
perhaps better way how the users see it.

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

 I don't think you'll gain anything by dropping X selections and replacing 
them by something else. The X selections mechanism isn't that simple and 
includes some braindamage, but then, whoever thinks IPC is simple is crazy.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/