Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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 michaeljt (subscriber, #39183)
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)
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).
Posted Nov 14, 2010 21:00 UTC (Sun) by quotemstr (subscriber, #45331)
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.
Posted Nov 15, 2010 10:10 UTC (Mon) by michaeljt (subscriber, #39183)
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.
Posted Nov 15, 2010 10:30 UTC (Mon) by michaeljt (subscriber, #39183)
> 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).
Posted Nov 16, 2010 13:00 UTC (Tue) by i3839 (guest, #31386)
Posted Nov 16, 2010 14:11 UTC (Tue) by michaeljt (subscriber, #39183)
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.
Posted Nov 16, 2010 22:26 UTC (Tue) by i3839 (guest, #31386)
Posted Nov 16, 2010 22:42 UTC (Tue) by michaeljt (subscriber, #39183)
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).
Posted Nov 19, 2010 22:13 UTC (Fri) by i3839 (guest, #31386)
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.)
Posted Nov 22, 2010 14:52 UTC (Mon) by michaeljt (subscriber, #39183)
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.
Posted Nov 25, 2010 21:44 UTC (Thu) by i3839 (guest, #31386)
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.
Posted Nov 25, 2010 21:56 UTC (Thu) by michaeljt (subscriber, #39183)
Just for interest I copied some text in Firefox and ran my clipboard format viewer. Here are the results:
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.
Posted Nov 26, 2010 22:26 UTC (Fri) by michaeljt (subscriber, #39183)
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.
Posted Nov 27, 2010 10:39 UTC (Sat) by i3839 (guest, #31386)
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 firstname.lastname@example.org).
Posted Dec 9, 2010 19:16 UTC (Thu) by Lestibournes (guest, #71790)
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.
Posted Nov 15, 2010 9:51 UTC (Mon) by michaeljt (subscriber, #39183)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds