So much for edit buttons... [LWN.net]

So much for edit buttons...

Posted Nov 6, 2010 21:25 UTC (Sat) by i3839 (guest, #31386)
In reply to: You must be joking by i3839
Parent article: LPC: Life after X

Same mistake as first: Forgot to mention that seeing the file path thing is the worst that would happen, in case a program just always blindly paste the text.

Then again, it's probably good if programs paste the text for types they can't handle, so the user can open the file directly.

That makes me think of one thing PO8 might find non-trivial: How to copy and paste complex data types around in a program, while using the same keys for system wide copy&paste.

Either just export and import that bit to a file of the format that program prefers, or just check before pasting whether it's the data the program copied before or something new. Simple enough.

Some other potentially scarry non-trivial problem: What if a program exits? Again, no problem, because shared memory would be used, so it's persistent data.

Aha! You might say, but if you use tmp files for colpex types, won't you leak data and fill the disk with them? At worst, yes, but that's what FF and other are already doing. Besides that, as the copy & paste thing would be implemented as a library, after copying something new the old thing can be deleted.

And so on and on. As I said, it's trivial.

to post comments

So much for edit buttons...

Posted Nov 6, 2010 21:36 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (7 responses)

Your scheme falls apart when users want to paste complex data types between multiple instances of the same program: yet another use-case gummed up by your ill-conceived scheme. We already have the program-exiting feature and know how to deal with it. Read the documentation of the actual protocols (hint: clipboard daemon in the X11 case).

Furthermore, "just seeing a file path" is NOT an acceptable outcome from a user-interface point of view. Again, that's the kind of statement only a developer could make. You seem to imagine a world of "simple" programs that would just slurp up the clipboard contents and use them. What you really want is content negotiation. We already have that.

This line of argumentation is exactly what's wrong with the people who want to reinvent X. They look at the complexity of the existing system, imagine it can be reduced, but when they try, they either create something worse or cut features, most of which people actually use. It really smacks of hubris to suppose that we're smarter than people were 20 years ago, and that we can do a better job of solving the same problems.

X is not the problem. Copy and paste isn't the problem. This asinine buzz around replacing X pops up every five years or so (remember Berlin?), and it has the same outcome every time. It's like saying, "my web browser doesn't pass the ACID3 test --- so let's reinvent TCP!"

So much for edit buttons...

Posted Nov 6, 2010 22:11 UTC (Sat) by i3839 (guest, #31386) [Link] (6 responses)

How so? It can make its own private type and dump data in there without bothering anyone else. I'd say copy and pasting between multiple instances of the same program is easiest as far as complex data goes.

> Furthermore, "just seeing a file path" is NOT an acceptable outcome from
> a user-interface point of view. Again, that's the kind of statement only
> a developer could make. You seem to imagine a world of "simple" programs
> that would just slurp up the clipboard contents and use them.

Yes, I'm a computer programmer, and by your attitude I guess you're not.

May I assume any technical discussion goes over your head and you're too stupid to follow what I say? I hope not, because I don't. You on the other hand seem to attribute my spartan approach to computering (Fluxbox, xterms, Nedit/Vim and LaTeX for the rest) to the fact I'm a programmer, and brush away my taste and opinion away as "something only a developer would say".

Pasting data is by definition slurping clipboard content and using it.

Now back to the discussion at hand:

> Furthermore, "just seeing a file path" is NOT an acceptable outcome from
> a user-interface point of view.

The alternative is that nothing would happen because the program didn't understand that format. So yes, I think it's a pretty acceptable outcome for something that can't work. And with my developers hat on, I'd say some outcome is better than nothing happening, because the latter is hard to debug and fix, while the first is plain and simple. For both users and developers. Users know what files are, developers know what's happening. But if you prefer the program can also not display anything, that doesn't change the CP system, though IMHO would be worse for the user experience.

As for your other ranting, I'm just saying that implementing a copy and paste system from scratch is technically trivial, no more and no less. It could be done in one day, maybe two. I just don't buy that copy & paste is hard stuff.

So much for edit buttons...

Posted Nov 6, 2010 22:22 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (3 responses)

I am a programmer, but I seem to be one of the few who gives a damn about the experience of ordinary users. We're talking about a general-purpose mechanism, not a way for you to copy a path from one xterm to another. Myopic design like yours is the reason Linux has had quite limited success on the desktop.

The alternative is that nothing would happen because the program didn't understand that format. So yes, I think it's a pretty acceptable outcome for something that can't work. And with my developers hat on, I'd say some outcome is better than nothing happening

Finally, you make a good point. It's better for the user to receive some feedback than nothing at all, but you present a false dichotomy here. Nothing prevents an application from presenting a dialog box that says in clear, understandable $LC_MESSAGES "Sorry, but I don't know how to paste an image in this document".

Users have only the foggiest notion of what a file is. Hell, they conflate files with pictures on their desktop. They certainly don't know about paths: they know about sequences of clicks that bring up the right pictures. Asking them to deal with seeing "/tmp/asd5FAB34/image-jpeg.clipboard.tmp" when they meant to paste a hiking picture into an email is just an idea completely divorced from reality.

If you want to make a system purely for yourself and your ilk, fine. But don't go claim that implementing a system is trivial, then force users to wear the same hairshirt that you do.

As for your other ranting, I'm just saying that implementing a copy and paste system from scratch is technically trivial, no more and no less. It could be done in one day, maybe two. I just don't buy that copy & paste is hard stuff.

Ah, good old-fashioned arguments from assertion. Well, go ahead and "don't buy" that copy-and-paste is inherently complex. But reality is there regardless of whether you choose to stick your fingers in your ears, squeeze your eyes shut, and sing "it's easy! I know it's easy! Easy, easy, easy!" As I said, it's only simple if you have simple needs. You have no right to assert that users shouldn't need more features than you personally happen to use.

So much for edit buttons...

Posted Nov 7, 2010 10:41 UTC (Sun) by i3839 (guest, #31386) [Link] (2 responses)

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.

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! ;-)

So much for edit buttons...

Posted Nov 7, 2010 13:03 UTC (Sun) by jond (subscriber, #37669) [Link] (1 responses)

You've said it's easy several times but *this* impartial observer, at least, hasn't seen anything to support that, just a lot of hot air. At this point I have to say "show me the code". Especially if it really is only a day or twos work.

So much for edit buttons...

Posted Nov 8, 2010 15:10 UTC (Mon) by i3839 (guest, #31386) [Link]

I'm thinking about it.

I just checked out the Wayland repo and might give it a stab later this week.

Personally I find decentralized input event handling more important than CP though.