So much for edit buttons...
So much for edit buttons...
Posted Nov 6, 2010 22:11 UTC (Sat) by i3839 (guest, #31386)In reply to: So much for edit buttons... by quotemstr
Parent article: LPC: Life after X
> 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.
Posted Nov 6, 2010 22:22 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (3 responses)
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.
Posted Nov 7, 2010 10:41 UTC (Sun)
by i3839 (guest, #31386)
[Link] (2 responses)
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.
Posted Nov 7, 2010 15:23 UTC (Sun)
by ccurtis (guest, #49713)
[Link] (1 responses)
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?
Posted Nov 7, 2010 15:30 UTC (Sun)
by ccurtis (guest, #49713)
[Link]
Now, why are threaded discussions on LWN so hard to follow - it should be easy! ;-)
Posted Nov 7, 2010 13:03 UTC (Sun)
by jond (subscriber, #37669)
[Link] (1 responses)
Posted Nov 8, 2010 15:10 UTC (Mon)
by i3839 (guest, #31386)
[Link]
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.
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.
So much for edit buttons...
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".
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...
Copy and Paste
Copy and Paste
So much for edit buttons...
So much for edit buttons...