|
|
Subscribe / Log in / New account

So much for edit buttons...

So much for edit buttons...

Posted Nov 7, 2010 10:41 UTC (Sun) by i3839 (guest, #31386)
In reply to: So much for edit buttons... by quotemstr
Parent article: LPC: Life after X

You still haven't given one example that makes copy & paste hard, you just keep up coming with details that change the user experience, but not the actual copy&paste system much. I'm not sticking my fingers in my ears, I just haven't heard anyone giving a good example what makes copy & paste hard.

You keep missing the power of text: That I'd put in the filename doesn't mean you have to do that in your program too. Instead of /tmp/image.jpg you could put in "This program can't paste JPEG images!", or whatever the hell you like. That is IMHO a lot better than a stupid pop-up (I hate those). And if people see something they don't like, they can close their eyes, do ctrl+z and pretend nothing happened.

The fundamental problem of your "Sorry, but I don't know how to paste an image in this document" is that it's the program failing the paste that has to say it, while it doesn't know about the type that you tried pasting. So now it has to know that the type it can't handle is an image. And then you make the mistake of making the copy & paste system more complicated by adding a text description of the type, and adding all those "error" handling everywhere. Copy & paste is not worth that extra complexity, that's the way how you get bloated software.

Because no one can tell me what makes copy & paste hard, I'll do it myself: To enter copy & paste hell you have to want to copy from a complex type and paste it as another complex type, THAT is where the madness lies. And any sane copy & paste system will not try to solve that at all, because it can't, it's not the right place. So I'm not saying that copy & paste is always easy, I'm just saying that implementing a copy & paste system is easy. And 95% of the time hell is avoided, and the 5% that wants to deal with it can do it themselves without making the rest of the system more complicated. And the way to solve the complex to complex problem is to solve it on a case by case base, with programs agreeing how to do it per case. And the agreeing on pretty much means choosing an intermediate complex type, or agree on the ordering of provided types. And to do all that the list of types system is sufficient as far as I can tell. Make the interface extensible, just to be sure, and it's done.

The hard part of introducing a copy & paste system is to let people agree on its features and interface, because there are always people that think it should be made more complicated than warranted.


to post comments

Copy and Paste

Posted Nov 7, 2010 15:23 UTC (Sun) by ccurtis (guest, #49713) [Link] (1 responses)

I do not understand what you two are squabbling about.

If an application builds a MIME message for each Cut/Copy operation, and receives a MIME message for each Paste, why does this not work?

The creator of the message can (in the case of a PDF reader, for example) present both text and pbm versions; the receiver of the message can take the text/plain part (if an xterm) or the image/pbm part (if an image editor), or prompt the user for the format they want if it so desires.

How the message is stored is immaterial - disk file, network server, whatever - why would this "text only" interface not work?

Copy and Paste

Posted Nov 7, 2010 15:30 UTC (Sun) by ccurtis (guest, #49713) [Link]

Bah. I didn't realize 90% of this article's comments are about C&P; I thought I reached the end of the thread. Sorry for the noise.

Now, why are threaded discussions on LWN so hard to follow - it should be easy! ;-)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds