You must be joking [LWN.net]

You must be joking

Posted Nov 6, 2010 20:48 UTC (Sat) by quotemstr (subscriber, #45331)
In reply to: You must be joking by i3839
Parent article: LPC: Life after X

In-band signaling doesn't work. What if I want to paste the text "/tmp/stupidimagefile.png (image/jpg)"? You're just replacing one complex scheme with another; out-of-band signaling is more robust and after all is said and done with your encoding stuff, it's probably less complex.

to post comments

You must be joking

Posted Nov 6, 2010 21:12 UTC (Sat) by i3839 (guest, #31386) [Link] (33 responses)

*sigh* I feared I would have to explain that too.

Best would be a copy&paste system that only supports text, but because people want to copy other crap, you have to support other crap somehow anyway. So yes, you have to add a type to the copied data. But instead of going the way of madness and trying to add a type for every bloody type of data there is, just add two: Normal plain text, and the extended plain text. The second is the file path + metadata (if needed). And low and behold, your copy&paste system is done and finished.

If you want to add network transparency, just copy the tmp file over. Simple as that. The CP system stays the same no matter what data types come and go.

Now instead of picking at unmentioned details, could anyone of you please come with real problems instead?

And no, I haven't thought it thoroughly through. There's no need, as I said, it's trivial stuff, as long as you don't shoot yourself in the foot.

So much for edit buttons...

Posted Nov 6, 2010 21:25 UTC (Sat) by i3839 (guest, #31386) [Link] (8 responses)

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.

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.

You must be joking

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

Only a developer could say the best copy-and-paste system would support only text. Your scheme falls apart because it relies on participating applications magically knowing the format of the data in the temporary file. Are they supposed to guess based on the file contents? You haven't eliminated the "every type there is problem"; instead, you've just pushed it down into a layer where it's even harder to get right. If you copy a spreadsheet, do you put CSV in the temporary file? What if you actually want to paste CSV? What if applications (especially across machines) don't guess file content types in the same way?

If you instead put the type information in the metadata, you basically have the system we have today *plus* the complexity of having to manage this temporary file and copy it across machines. Preemptively? On demand? Over what transport? Do transfers block the GUI?

Plus, you lost the ability to send multiple alternative data types. If I copy some text from a word processor and paste it into another word process, I want the formatting to be retained. If I paste that text into a terminal, I want plain text. There's no way to achive that without some fallback provision in the copy and paste system. This is a feature users want. They use it all the time, today.

You haven't solved any problems. You've obfuscated them and made them *worse* while removing features at the same time.

You must be joking

Posted Nov 6, 2010 21:51 UTC (Sat) by i3839 (guest, #31386) [Link] (20 responses)

> Your scheme falls apart because it relies on participating applications
> magically knowing the format of the data in the temporary file. Are they
> supposed to guess based on the file contents? You haven't eliminated the
> "every type there is problem"; instead, you've just pushed it down into a
> layer where it's even harder to get right.

Umm, that's a known problem and solved, as far it's possible to solve, for regular files. I'm pushing it to the place where this problem is already solved, instead of reinventing the wheel awkwardly. File extension seems good enough, but if you want MIME or whatever, that's easy enough to add.

> If you instead put the type information in the metadata, you basically
> have the system we have today *plus* the complexity of having to manage
> this temporary file and copy it across machines. Preemptively? On demand?
> Over what transport? Do transfers block the GUI?

No, today there is too much information passing between programs. I know nothing about it, but that closing an app makes the copied thing disappear tells me that there is too much cooperation going on when copying/pasting happens.

The copying is only needed for network transparency, if you want to copy stuff between local and remote apps. It's not hard to implement.

> Plus, you lost the ability to send multiple alternative data types. If
> I copy some text from a word processor and paste it into another word
> process, I want the formatting to be retained. If I paste that text into
> a terminal, I want plain text. There's no way to achive that without
> some fallback provision in the copy and paste system. This is a feature
> users want. They use it all the time, today.

This is actually a good point you make, finally.

Can't say I ever felt the need to do thing like this, but here goes:

Add a way to copy something multiple times in different formats, and let the program pasting it choose the type it prefers.

So instead of a singular item, you suddenly got a list or array of items. I give you that, my simple scheme before wouldn't handle this too well, unnecessarily cludgey for text if you pass the file path as text already. So instead always have a text representation (also the path in case there's nothing else), and a (hopefully usually empty) list of files.

This pushes the complexity of handling multiple types to where it belongs, while keeping the copy and paste system itself simple.

> You haven't solved any problems. You've obfuscated them and made them
> *worse* while removing features at the same time.

What problems? I don't see any.

You must be joking

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

Add a way to copy something multiple times in different formats, and let the program pasting it choose the type it prefers.
So instead of a singular item, you suddenly got a list or array of items. I give you that, my simple scheme before wouldn't handle this too well, unnecessarily cludgey for text if you pass the file path as text already. So instead always have a text representation (also the path in case there's nothing else), and a (hopefully usually empty) list of files.
This pushes the complexity of handling multiple types to where it belongs, while keeping the copy and paste system itself simple.

All right. Now we're arrived at a complex tagged array scheme with server-managed copying. In what specific way is this better than (or hell, different from) what we have today?

You must be joking

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

It's not server managed, it's implemented as a library function, for one. There's no complex copying around, only simple copying around when needed.

Second, primarily it's a simple text based CP system, but for the people that want silly complex types, it supports an array of path/type pairs. That is where the API ends and the system is complete. Technically it's all very simple and straightforward.

As for whether it's better or not than the current system, I don't know. Read my first post, all I'm saying is that you don't need X for copy&paste and that it's trivial enough to implement.

You must be joking

Posted Nov 8, 2010 12:47 UTC (Mon) by dgm (subscriber, #49227) [Link] (17 responses)

> Add a way to copy something multiple times in different formats, and let the program pasting it choose the type it prefers.

What a waste.

You need to realize that Cut and Paste is really an IPC, and one that requieres data format negotiation.

Also, you cannot rely on temporary files for that on X11, both applications need not be on the same machine, nor on the same network. Maybe they cannot see eachother directly, either.

You must be joking

Posted Nov 8, 2010 15:26 UTC (Mon) by mjthayer (guest, #39183) [Link] (16 responses)

> Also, you cannot rely on temporary files for that on X11, both applications need not be on the same machine, nor on the same network. Maybe they cannot see eachother directly, either.

You can also implement the clipboard as something purely local but proxyable, rather than coupling it so tightly with the window system. That would have the advantage that it can be more easily proxied in other situations than just the one you originally thought of (e.g. between virtual machines or different Synergy desktops). Just for fun, here is an imaginary non-X11-based clipboard API based on a well-known location in the filesystem (e.g. /var/spool/clipboard.tar).

* The application placing data in the clipboard creates a tar archive. The first file in the archive is a text file with a list of the MIME types provided, one per line. The other files contain the clipboard data in different formats, probably one file per MIME type and as few as possible (say one specialised format, one common one and a text fallback). The application atomically renames the tar file to /var/spool/clipboard.tar.

* An application which can handle clipboard data waits for file change notifications on /var/spool/clipboard.tar. When it gets one it reads the list of MIME types to see if it can handle one and if so enables its "paste" menu entry or whatever it does. When the user pastes data it reads the whole archive until it finds the format it can handle.

A couple of notes about the imaginary protocol:

* It is probably highly inefficient, although again copy and paste is not something you do several times a second.

* It could be integrated with the X11 clipboard protocol by a suitable X11 proxy client with the big caveat that the client would need to know about (though not to understand) lots of different data formats so that when an X11 client offers clipboard data the proxy client would know which formats are worth grabbing and which are not.

Simple is good enough

Posted Nov 14, 2010 17:06 UTC (Sun) by i3839 (guest, #31386) [Link] (15 responses)

Exactly, this is more or less the approach I was thinking about (high level, not the details. I don't see the need for tar, for instance). Have a simple copy and paste system which can be easily used by all applications, including network or X proxies and non-graphical programs.

Simplicity is more important than efficiency. The alternative would be to have some format negotiation and directly copying between programs when needed (for non-text formats), like X has. This is not worth the complexity.

All that's needed is a way to store mutiple formats and retrieve them, as wel as serialisation and notifications when things get copied (for proxies).

Simple is good enough

Posted Nov 14, 2010 21:00 UTC (Sun) by quotemstr (subscriber, #45331) [Link] (13 responses)

"Why does copying this image freeze the program for 30 seconds? Lol that doesnt happen under Windows."

That's what users will begin saying if your scheme is implemented and we don't have application-to-application copying. What X11 jacobins like you don't realize is that current design choices were made *for a reason* and shouldn't be lightly abandoned.

Simple is good enough

Posted Nov 15, 2010 10:10 UTC (Mon) by mjthayer (guest, #39183) [Link] (12 responses)

> "Why does copying this image freeze the program for 30 seconds? Lol that doesnt happen under Windows."

If that was also addressed to me, I will make an attempt at defending my proposal (consider the correction I added above as part of it).

* Clipboard data is written to a file on disk in order to share it, but due to disk caching that doesn't have to mean that the disk has to be a bottleneck (even disregarding the fact that /var/clipboard could be a tmpfs). This would need real life testing of course.
* Some latency is acceptable (ESR's estimate is 0.7 seconds - http://www.faqs.org/docs/artu/ch10s01.html). In this case we have additional room for manoeuvre, as we also have the time the user needs to switch from the copying to the pasting application.
* I will also point out that this proposal actually removes a potential source of latency (one that does occur in the wild) with the X11 selection protocol - when an application pastes X11 clipboard data it requires several rounds of communication between the two applications via the X server. If the application offering the data is currently busy the application pasting will often freeze until the data can be served. With the scheme I proposed the data will be available at once.

I realise that it might still not be workable despite all that, but I do think that there is a chance it might be.

Simple is good enough

Posted Nov 15, 2010 10:30 UTC (Mon) by mjthayer (guest, #39183) [Link] (10 responses)

>> "Why does copying this image freeze the program for 30 seconds? Lol that doesnt happen under Windows."

> If that was also addressed to me, I will make an attempt at defending my proposal (consider the correction I added above as part of it).

Replying to myself. One clear weakness of my proposal would be that it might not work well with select and middle button paste, as selecting is something you do more often than copying (again, that would need testing to be sure). I would give it more chances of working with drag and drop (which I personally prefer over middle button paste, but I greatly fear I am in a minority here with that).

Simple is good enough

Posted Nov 16, 2010 13:00 UTC (Tue) by i3839 (guest, #31386) [Link] (9 responses)

Not really. People probably don't want to copy and paste complex things
like images with select and middle mouse button. So if applications are
smart they only copy simple things that are quick to copy when selecting,
and only do the slow copy when users explicitly copy something.

Simple is good enough

Posted Nov 16, 2010 14:11 UTC (Tue) by mjthayer (guest, #39183) [Link] (8 responses)

> So if applications are smart they only copy simple things that are quick to copy when selecting, and only do the slow copy when users explicitly copy something.

Shouldn't applications be doing what the user asks them to rather than being smart? Selecting and middle click pasting an image works now. If the user selects it, should the application really assume that they don't want to paste it? Of course, it might still turn out that users don't select things often enough that the overhead would be a big issue.

Simple is good enough

Posted Nov 16, 2010 22:26 UTC (Tue) by i3839 (guest, #31386) [Link] (7 responses)

It depends on the program and context. If you select an image in a browser I wouldn't copy the image. But if it's an image editing program, I would.
But copying it into a hundred formats isn't something you should do for every selection of any random thing (or ever, but if you do...).

Simple is good enough

Posted Nov 16, 2010 22:42 UTC (Tue) by mjthayer (guest, #39183) [Link] (6 responses)

> It depends on the program and context. If you select an image in a browser I wouldn't copy the image. But if it's an image editing program, I would.

This does happen currently though (I tested it earlier today).

> But copying it into a hundred formats isn't something you should do for every selection of any random thing (or ever, but if you do...).

I changed that aspect of the proposal in a previous comment - in the new version a file containing a single mime type (with a well-known magic number) is saved to disk. To handle conversions, a (large) set of filters is installed on the system, and the application reading the clipboard must iterate through the installed filters to find ones which convert the file to a format it can use. This is roughly what BeOS did, which apparently worked well (or so I am told by a colleague who developed for BeOS).

Simple is good enough

Posted Nov 19, 2010 22:13 UTC (Fri) by i3839 (guest, #31386) [Link] (5 responses)

> I changed that aspect of the proposal in a previous comment - in the new
> version a file containing a single mime type (with a well-known magic
> number) is saved to disk. To handle conversions, a (large) set of filters
> is installed on the system, and the application reading the clipboard
> must iterate through the installed filters to find ones which convert the
> file to a format it can use. This is roughly what BeOS did, which
> apparently worked well (or so I am told by a colleague who developed for
> BeOS).

Well, the problem is that for complex types you can't easily convert from one to the other, because only the program doing the copying has all the info.

Example: If you copy a bit of a webpage, it can be either plain text, the raw HTML code, or formatted text depending on the style etc. Converting to plain text is almost always possible, but anything else doesn't really work. So a single mime type isn't always sufficient.

There are two sides to a copy and paste system: The program ABI to do the copying and pasting, and the system ABI how it's actually done. I think the latter shouldn't be set in stone, only the former, to keep the implementation flexible. So all copying and pasting should happen through the system installed copy&paste library, or the copy and paste programs (simple front-ends for the lib).

(I still haven't found to start implementing this, hopefully next week.)

Simple is good enough

Posted Nov 22, 2010 14:52 UTC (Mon) by mjthayer (guest, #39183) [Link] (4 responses)

> Well, the problem is that for complex types you can't easily convert from one to the other, because only the program doing the copying has all the info.

Actually the idea was that the application doing the copying provided the data in its native/internal format, which by definition should have all the information. It could always define an x- or a vnd. mime format for this and provide whatever converters it wanted to transform that data into other formats (they could probably double up as export filters too).

> Example: If you copy a bit of a webpage, it can be either plain text, the raw HTML code, or formatted text depending on the style etc. Converting to plain text is almost always possible, but anything else doesn't really work. So a single mime type isn't always sufficient.

In this case the native format is presumably "text/html", which should be convertable to either plain text or formatted text without the copying application even having to provide its own converters.

Simple is good enough

Posted Nov 25, 2010 21:44 UTC (Thu) by i3839 (guest, #31386) [Link] (3 responses)

Problem is that in the case of html, you generally lose the formatting information because that's not in the part you copied, but higher up or in a css file. So there is no native format, you don't want to copy raw html code into a word processor, nor the plain text, but something that more or less looks like what you copied. Not to mention that usually the selected part is "broken" html because not all tags are closed. So it's not that simple and I don't think it's safe to get rid of the list support.

For images and other data formats with an obvious raw format are much easier and better suited for automatic convertion. That can be done automatically without changing the API.

Simple is good enough

Posted Nov 25, 2010 21:56 UTC (Thu) by mjthayer (guest, #39183) [Link]

> Problem is that in the case of html, you generally lose the formatting information because that's not in the part you copied, but higher up or in a css file. So there is no native format, you don't want to copy raw html code into a word processor, nor the plain text, but something that more or less looks like what you copied.

Just for interest I copied some text in Firefox and ran my clipboard format viewer. Here are the results:

$ ../tmp/viewclipformats
Found clipboard format: TIMESTAMP
Found clipboard format: TARGETS
Found clipboard format: MULTIPLE
Found clipboard format: text/html
Found clipboard format: text/_moz_htmlcontext
Found clipboard format: text/_moz_htmlinfo
Found clipboard format: UTF8_STRING
Found clipboard format: COMPOUND_TEXT
Found clipboard format: TEXT
Found clipboard format: STRING
Found clipboard format: text/x-moz-url-priv

Without knowing, it wouldn't surprise me if one of those contained both the html and the formatting information, which I think should be feasible with my proposal too.

Simple is good enough

Posted Nov 26, 2010 22:26 UTC (Fri) by mjthayer (guest, #39183) [Link] (1 responses)

You also have to ask, when an application puts HTML data into the clipboard, what data it is actually putting there. When I select a section of text, pictures and whatever in Firefox and copy I get HTML data in the clipboard. But Firefox can't just put the source of the document from the point where the selection begins to the point where it ends into the clipboard, as it is announcing HTML data, and as you point out, that wouldn't be HTML, it would be broken HTML. So Firefox has no choice but to massage the HTML data anyway, and if it is doing that already, adding the style information inline is no great hardship.

Of course, if you want to reuse that data as is as HTML for some other web page then you are probably out of luck, but if you think of it that makes no sense anyway - if you want to do that you should probably be copying the source of the HTML as plain text. If you select and copy part of a page in Firefox, chances are that what you are actually about to do is to paste it either as plain text (the text visible on the page, not the HTML source) or as formatted text into e.g. OpenOffice.

And if you were copying the data inside some visual HTML editor, it would probably still not make sense for the editor to insert the data as naive HTML - chances are there would be no way to paste the data in any form resembling the source of the page the editor was generating, and in any case, if you were trying to get at the generated source it would make more sense to ask the editor directly than copying and pasting to get at it. In fact I would expect the visual editor to use some internal format which was not valid HTML at all when copying to the clipboard, but which another instance of the editor would know what to do with when pasting it. It might provide a filter to convert it to HTML, but not for the purposes of viewing the source - you don't use the clipboard for that - but rather as a stepping stone for converting it to OOXML or something else.

Hope that made sense, as I am rather short of sleep currently. I would really like to be clear that I am not trying to argue for the sake of arguing here, but rather because responding to the points you make forces me to think things through myself.

Simple is good enough

Posted Nov 27, 2010 10:39 UTC (Sat) by i3839 (guest, #31386) [Link]

> I would really like to be clear that I am not trying to argue for the
> sake of arguing here, but rather because responding to the points you
> make forces me to think things through myself.

Same here, we're trying to figure out if a list of formats is really needed, or if always providing only one and having convertors is sufficient. This choice determines the API, so it's pretty important.

Only having one format and providing convertors is simpler, but less complete. My main concern is that it's not always sufficient, or that it makes implementing copy harder than necessary for some applications, because they have to create one "complete" format and convertors.

Another concern is that you convert from simple->complex->simple, when also supporting a complex type, hoping that the "simple" in the end is the same as what you started with. So the unrelated complex type makes simple types more complex too, with too much room for errors in my opinion. Or in other words, copying simple types is not simple anymore, if you also copy a complex one.

Lastly, I don't really see a way to support multiple types when pasting. It should be the pasting program's decision what type to paste, if it supports multiple types. I don't see another way than supporting a list of types in the pasting API anyway, and then you can as well support lists in the copy API too.

I think you make too many assumptions about what the user or pasting program expects in your line of thinking.

All in all I think the automatic convertion idea is good, but not always sufficient. Combined with today's multiple format support in applications, I think it's best to support multiple formats, but to encourage convertor usage when possible.

Then when someone pastes something the lists are compared, and if they have no common format, a convertor is used.

A list of formats is basically "more of the same", so I think the added complexity, both for the API and implementation, is small enough.

Now we just have to find some time to implement this. I think I'll give it a stab next week. I'll keep you informed (my email address is indan@nul.nu).

Simple is good enough

Posted Dec 9, 2010 19:16 UTC (Thu) by Lestibournes (guest, #71790) [Link]

Maybe something like this will work:
1. Program A indicates that it is ready to supply data by writing its identifier to clipboard/source.
2. Program B requests the data by writing its identifier to clipboard/destination.
3. Program A writes the data files in clipboard/data.
4. Program A indicates that it finished writing the data by erasing the content of clipboard/source and clipboard/destination.
5. Program B reads the data files from clipboard/data.

If no one requests the data from Program A, then it will still dump the data when it terminates. The only weaknesses I detect are a delay when the Paste operation is performed, and that the data will be lost if Program A crashes. There should be a separate clipboard folder for each session to avoid conflicts such as two users who share an account and override each other's Copy operations.

Simple is good enough

Posted Nov 15, 2010 9:51 UTC (Mon) by mjthayer (guest, #39183) [Link]

> Exactly, this is more or less the approach I was thinking about (high level, not the details. I don't see the need for tar, for instance).

I have been turning this over in my head since I posted that and have refined it somewhat. Rather than creating a tar file it should be enough to create a standard file in a known mime format with a usable magic number (note that the opendesktop.org mime specification allows for adding custom mime formats complete with magic numbers to a system). This would of course mean that text data would also need to be preceded by a mime tag, which I recognise makes the system slightly uglier, but also more reliable. Conversions could be handled in the BeOS way, which is to register conversion filters with the system (shared objects or just executable filters - in the end they need to be loaded from disk one way or another, so it might not make much difference). An application pasting clipboard data of a mime type it couldn't handle could enumerate the available filters to see if one of them helped.

An X11 application using this clipboard should of course start a proxy application - preferably a well known singleton application - which would keep the clipboard in sync with the traditional X11 one. This would allow for painless transition (I say transition, but there is no reason this sort of compatibility shouldn't be maintained for ever). Perhaps (although unlikely) I will try to get this working some time. I already maintain an X11 clipboard proxy tool that could be adapted to do the job.

You must be joking

Posted Nov 7, 2010 5:14 UTC (Sun) by drag (guest, #31333) [Link] (1 responses)

> If you instead put the type information in the metadata, you basically have the system we have today *plus* the complexity of having to manage this temporary file and copy it across machines. Preemptively? On demand? Over what transport? Do transfers block the GUI?

If copying non-text data you just have to use a URL to reference the resource.
http://blah/
file://blah/
sftp://blah/

Etc.

Then you let the application figure it out. If it does not know how to handle the file then it can display a error or just paste the text link or something.

This is were things like GVFS come in handy. Apps that support GVFS it's easy to do this... you just let GVFS handle the details about the connection to the service and then have the program figure out what to do with the file.

For non-gvfs programs you can theoretically just pass the URL through /home/blah/.gvfs/etc/etc/ and expose GVFS through FUSE.

You must be joking

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

Last I checked you can copy and past multiple files at once.