LPC: Life after X
LPC: Life after X
Posted Nov 6, 2010 13:55 UTC (Sat) by kjp (guest, #39639)Parent article: LPC: Life after X
Posted Nov 6, 2010 17:40 UTC (Sat)
by i3839 (guest, #31386)
[Link] (73 responses)
I'd probably do it via shared memory, but there are plenty of
Posted Nov 6, 2010 19:30 UTC (Sat)
by PO8 (guest, #41661)
[Link] (72 responses)
HA Ha ha ha... you were joking, right?
I think that X stands as a 20-year demonstration of the opposite proposition. I used to think like you did, and swore at one point a while back that I would clean up X's cut-copy-paste issues. I even publicly solicited help, although I found it curious that the more experienced that people were with it, the more they seemed to not want to get involved :-). Once I investigated the scope of the problem, I just gave up.
The current ICCCM solution to X cut-copy-paste is horrible: incomplete, inadequately honored, and confusing as hell for users and developers. This is *not* because smart people haven't thought hard about the problem, individually and collectively. It's because cut-copy-paste is hard.
I once put an entire software engineering class through a six-week exercise in just trying to provide an adequate specification for X cut-copy-paste behavior. It was a total failure, and the students mostly ended up hating me. They felt like idiots because they couldn't get their heads around this "trivial-looking" problem. I hope it taught them some valuable lessons about requirements specification, anyhow.
Cut-copy-paste is the UI monster in the closet. Back away slowly.
Posted Nov 6, 2010 20:21 UTC (Sat)
by i3839 (guest, #31386)
[Link] (71 responses)
You can try to make it awfully complicated by trying to copy and paste other stuff than text and not choosing a common character encoding (utf8), but then you have yourself to blame, not the trivial problem at hand.
And any sane copy&paste implementation that supports "complex" types is a simple text one at heart where the programs that want to support things like pictures do that by passing the needed information on in the form of text, and the complex data is just a temp file. Then they can mess up the extension area as much as they want without breaking simple text copy&paste for the rest of us.
Limiting the scope of something is better software engineering than trying to support everything.
But as you seem to have some experience with it, please enlighten us with one example why copy and paste is oh so hard.
Writing a 3D driver with decent performance, now that is non-trivial.
Posted Nov 6, 2010 20:30 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (36 responses)
Posted Nov 6, 2010 20:46 UTC (Sat)
by i3839 (guest, #31386)
[Link] (35 responses)
> And any sane copy&paste implementation that supports "complex" types is
To clarify, "the needed information" is not the image data, but as you point out, a file path and other metadata, if needed.
So you won't get garbage, but something like "/tmp/stupidimagefile.png" (and perhaps the MIME type).
Does this addresses your point?
Posted Nov 6, 2010 20:48 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (34 responses)
Posted Nov 6, 2010 21:12 UTC (Sat)
by i3839 (guest, #31386)
[Link] (33 responses)
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.
Posted Nov 6, 2010 21:25 UTC (Sat)
by i3839 (guest, #31386)
[Link] (8 responses)
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.
Posted Nov 6, 2010 21:36 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (7 responses)
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!"
Posted Nov 6, 2010 22:11 UTC (Sat)
by i3839 (guest, #31386)
[Link] (6 responses)
> Furthermore, "just seeing a file path" is NOT an acceptable outcome from
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
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.
Posted Nov 6, 2010 21:25 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (23 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?
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.
Posted Nov 6, 2010 21:51 UTC (Sat)
by i3839 (guest, #31386)
[Link] (20 responses)
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
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
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
What problems? I don't see any.
Posted Nov 6, 2010 21:54 UTC (Sat)
by quotemstr (subscriber, #45331)
[Link] (1 responses)
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?
Posted Nov 6, 2010 22:18 UTC (Sat)
by i3839 (guest, #31386)
[Link]
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.
Posted Nov 8, 2010 12:47 UTC (Mon)
by dgm (subscriber, #49227)
[Link] (17 responses)
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.
Posted Nov 8, 2010 15:26 UTC (Mon)
by mjthayer (guest, #39183)
[Link] (16 responses)
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.
Posted Nov 14, 2010 17:06 UTC (Sun)
by i3839 (guest, #31386)
[Link] (15 responses)
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)
[Link] (13 responses)
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 mjthayer (guest, #39183)
[Link] (12 responses)
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.
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 mjthayer (guest, #39183)
[Link] (10 responses)
> 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)
[Link] (9 responses)
Posted Nov 16, 2010 14:11 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (8 responses)
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)
[Link] (7 responses)
Posted Nov 16, 2010 22:42 UTC (Tue)
by mjthayer (guest, #39183)
[Link] (6 responses)
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)
[Link] (5 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.
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 mjthayer (guest, #39183)
[Link] (4 responses)
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)
[Link] (3 responses)
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 mjthayer (guest, #39183)
[Link]
Just for interest I copied some text in Firefox and ran my clipboard format viewer. Here are the results:
$ ../tmp/viewclipformats
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 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.
Posted Nov 27, 2010 10:39 UTC (Sat)
by i3839 (guest, #31386)
[Link]
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).
Posted Dec 9, 2010 19:16 UTC (Thu)
by Lestibournes (guest, #71790)
[Link]
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 mjthayer (guest, #39183)
[Link]
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.
Posted Nov 7, 2010 5:14 UTC (Sun)
by drag (guest, #31333)
[Link] (1 responses)
If copying non-text data you just have to use a URL to reference the resource.
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.
Posted Nov 7, 2010 13:07 UTC (Sun)
by jond (subscriber, #37669)
[Link]
Posted Nov 7, 2010 3:51 UTC (Sun)
by zander76 (guest, #6889)
[Link] (33 responses)
If an application knows how to copy and paste to itself then it already knows a fair about about what it is copy and pasting. If I was going to write a copy/paste function in an image editor lets say, then it would obviously know about the bits but perhaps I could attach some header information like image type.
Ones I was that far then it would seem to me that I could just copy that information into a global queue. On paste I could then pass the structure to the application. It would be up to the application to deal with images, text or whatever else.
It doesn't *seem* that difficult. You got me, what am I missing? I am kind of curious now.
Thanks
Posted Nov 7, 2010 4:06 UTC (Sun)
by dlang (guest, #313)
[Link] (14 responses)
the person up thread who took his class through the process of trying to specify (not even implement) the correct behavior in all conditions probably has a lot of info that would be very interesting and educational if he could take the time to write it up (especially if the writeup can talk about a lot of the dead-ends that seem so attractive)
Posted Nov 7, 2010 4:30 UTC (Sun)
by zander76 (guest, #6889)
[Link]
Students tend to under or over design things. To loosely quote Linus "It's simple to make things complex and complex to make things simple". It does take a fair amount of experience to hit that middle ground.
It is very easy to make a complicated mess especially when you are trying to make everybody in the world happy and address every problem before you start. You will never get passed the design phase.
Now don't get me wrong I am not stating that this is the case. I am simply stating that I could see how this could get way out of control. This is especially true when with students trying to account for every problem. In the working world you tend to spend less time on use cases and more time on getting the job done so you can go home :)
Posted Nov 7, 2010 4:55 UTC (Sun)
by PO8 (guest, #41661)
[Link] (11 responses)
Hope this helps.
Posted Nov 7, 2010 7:53 UTC (Sun)
by dlang (guest, #313)
[Link] (7 responses)
I've only been using linux as my primary desktop for 13 years or so, so I'm abit of a novice in understanding all the nuances of why the two are separate in the first place or how to know when each is being used :-)
Posted Nov 8, 2010 6:08 UTC (Mon)
by mfedyk (guest, #55303)
[Link] (4 responses)
I like being able to copy and paste with just the mouse and not having to go through any menus to do so. I end up cursing the lack of that feature whenever I'm on another platform
Posted Nov 8, 2010 7:16 UTC (Mon)
by dlang (guest, #313)
[Link]
Posted Nov 8, 2010 15:43 UTC (Mon)
by foom (subscriber, #14868)
[Link] (2 responses)
Posted Nov 8, 2010 21:39 UTC (Mon)
by mfedyk (guest, #55303)
[Link] (1 responses)
Note the "with just the mouse" part...
I use the CLI all the time, but sometimes I don't have a free hand to reach for the keyboard (using screwdriver, using someone else's computer to instruct them, etc.) and just want to do something quickly with the mouse only.
Posted Nov 11, 2010 16:10 UTC (Thu)
by cdmiller (guest, #2813)
[Link]
Posted Nov 8, 2010 13:32 UTC (Mon)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
X has these things called selections. How they are used is defined outside X, you could run an X server and a suite of apps that had no selections, or had a dozen all named after capital cities. X does not care.
For interoperability you need to agree how to use them. The ICCCM provided a good enough description for its day, but apparently in the late 1990s reading comprehension among software developers declined, and Qt managed to screw it up repeatedly, so there is also a FD.O document which spells it out.
So, this names selections including PRIMARY and CLIPBOARD. The PRIMARY selection is to be set to whatever the user last explicitly selected. By convention apps ask for the contents of this selection and insert it when you press middle-button.
The CLIPBOARD selection is maintained separately by explicit cut or copy operations. Most apps ask for the contents of this selection when you use their paste operation.
Selections are also used in drag-and-drop functionality. They have several features that the average My First Clipboard idea doesn't handle
Low overhead. Rather than storing whatever you select or cut into some OS-provided "clipboard" where it will mysteriously waste a lot of RAM*, the selections exist only in the source application until needed. X just tracks a window ID and a timestamp.
Really the worst problem is that application developers don't care. They refuse to "pay their taxes" as it has been called, by implementing features that require some work on their part to deliver a better experience for the end user across all applications. This isn't just about the clipboard, it's a widespread problem. They may hard-code a date format that annoys non-Americans, or misbehave when multiple monitors are used, or any number of things. And it's not just on X, this is a problem on every platform, only the specifics vary.
I really mean it about them not caring. For a while I filed bugs against apps that got this stuff wrong. But the response was almost always hostile.
* A lot of designs don't consider this. Users expect that somehow the computer "knows" that they intended to just throw away the 50MB of charts they just cut from a document, but they needed to keep the 15MB image they cut the next day. There are no ultimate solutions here, like window focus it's a matter of best effort.
Posted Nov 18, 2010 9:45 UTC (Thu)
by renox (guest, #23785)
[Link]
Which is why, I always look at propositions which want to replace things done by a common server by things done by all the applications with a lot of skepticism..
One of the example is XCB which AFAIK is still not implemented by Qt or GTK even though it was supposed to allow better threading.
Posted Nov 7, 2010 11:20 UTC (Sun)
by quotemstr (subscriber, #45331)
[Link]
Posted Nov 7, 2010 13:58 UTC (Sun)
by foom (subscriber, #14868)
[Link] (1 responses)
> The best means we have for identifying media type right now is MIME-types. Unfortunately, they are really too incomplete and disorganized for CCP purposes. Their ontology is only two levels deep and highly incomplete.
You might be interested to check out Apple's solution to that problem, Uniform Type Identifiers (first introduced in OSX 10.4, it's been slowly introduced into more and more data transfer APIs). They are multi-level hierarchical, where the hierarchy is defined outside of the type-name.
http://developer.apple.com/library/mac/documentation/File...
Also see the "Pasteboard Concepts" article.
http://developer.apple.com/library/mac/documentation/Coco...
Posted Nov 8, 2010 7:52 UTC (Mon)
by PO8 (guest, #41661)
[Link]
Posted Nov 7, 2010 7:02 UTC (Sun)
by mfedyk (guest, #55303)
[Link]
yes, very much looking forward to this article.
Posted Nov 7, 2010 4:08 UTC (Sun)
by dlang (guest, #313)
[Link] (17 responses)
think about doing a text cut-n-paste between two terminal windows of different widths where the source is multiple lines, some of which wrap.
many windows apps do this wrong, most *nix apps handle this correctly.
Posted Nov 7, 2010 4:13 UTC (Sun)
by zander76 (guest, #6889)
[Link] (1 responses)
Posted Nov 7, 2010 4:35 UTC (Sun)
by zander76 (guest, #6889)
[Link]
Posted Nov 7, 2010 4:58 UTC (Sun)
by drag (guest, #31333)
[Link] (14 responses)
In Linux on Gnome:
1. Open up Gnome-terminal. Highlight some text and right click, select copy. Highlight some other text.
Notice how you have 2 copy-n-paste buffers. Highlighting text makes the first buffer go away and be replaced by new text. This makes it almost entirely worthless for anything except working with a terminal. Using middlelick copy is one of those habits I wish I can break myself from doing.
The second buffer works in a sane way.
Almost.
5. Open up firefox. Highlight some text, Right click copy.
Notice something wrong?
The only people that get it right are Gnome apps that religiously follow the HIG. Probably KDE-only apps get it right, too. Everybody else gets it wrong almost every single time. Some apps will clear everything out every time. Some apps will override one buffer with another in order to be helpful. All sorts of really weird and crappy behavior.
It's something that is fundamentally broken with X and has been since the beginning of time. I don't think there is any sane way to fix it as nobody has been able to do so. Even with aggressive clipboard managers it's still a bit hit or miss if it works sometimes.
Posted Nov 7, 2010 5:05 UTC (Sun)
by dlang (guest, #313)
[Link] (13 responses)
I do get annoyed once in a while by apps that use the second clipboard, and I've never taken the time to figure out the difference between the two. but for the most part I find that if just highlighting doesn't work, shift + highlighting almost always does.
Posted Nov 7, 2010 13:51 UTC (Sun)
by drag (guest, #31333)
[Link] (12 responses)
A simple example is try pasting a URL into your browser bar, at pretty much any point without opening a extra tag. Also many many times I'll lose my buffer by simply clicking on a terminal window and accidentally highlighting some whitespace or some tiny portion of text.
The advantage to the second buffer is mainly that you control when things are inserted. With a primary, traditional, X copy buffer it is often wiped out many times during the course of normal text manipulation in a GUI.
I wouldn't mind having 2 buffers at all except that how applications and X handles these buffers is broken. It's very inconsistent so you either have to learn how each and every application you typically use is going to behave, or you just end up having to copy stuff multiple times quite often.
Posted Nov 8, 2010 2:46 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (11 responses)
Posted Nov 8, 2010 3:39 UTC (Mon)
by dlang (guest, #313)
[Link] (2 responses)
Posted Nov 8, 2010 7:07 UTC (Mon)
by mp (subscriber, #5615)
[Link] (1 responses)
Posted Nov 8, 2010 7:14 UTC (Mon)
by dlang (guest, #313)
[Link]
Posted Nov 8, 2010 3:54 UTC (Mon)
by sfeam (subscriber, #2841)
[Link] (1 responses)
Posted Nov 8, 2010 15:53 UTC (Mon)
by jackb (guest, #41909)
[Link]
Posted Nov 8, 2010 8:56 UTC (Mon)
by nicooo (guest, #69134)
[Link]
Posted Nov 9, 2010 5:20 UTC (Tue)
by njs (subscriber, #40338)
[Link] (2 responses)
Posted Nov 14, 2010 4:57 UTC (Sun)
by tnoo (subscriber, #20427)
[Link] (1 responses)
Posted Nov 14, 2010 6:10 UTC (Sun)
by bronson (subscriber, #4806)
[Link]
Seems a rather weak reason to hate a browser.
Posted Nov 15, 2010 16:24 UTC (Mon)
by wookey (guest, #5501)
[Link]
Ctrl-U can still be made to work (as 'clear line/box'), but it gets harder to find the rune every year. A button to prod for the same function would indeed be a useful alternative.
Like many here I find middle-button paste to be one of the finest things about GNU/Linux, and it's extremely tiresome when you get apps that don't do it right. I really hope it does not get sacrificed as part of the GUI re-architecting that it looks like we are headed for.
I use remote-X-over-ssh for graphical apps fairly regularly and it's extremely useful, but accept the argument that we can achieve much the same effect by other means (SPICE/VNC/NX/whatever). I hope that does indeed come to pass.
Posted Nov 18, 2010 3:52 UTC (Thu)
by gmatht (guest, #58961)
[Link]
With Firefox, middle-click the icon to the left of the icon bar. However this does not work for searching for non-urls; see the patch to implement middle-clicking on the search icon at: https://bugzilla.mozilla.org/show_bug.cgi?id=414849. I would be particularly interested to know if you would find the functionality implemented by this patch useful.
Posted Nov 6, 2010 18:14 UTC (Sat)
by drag (guest, #31333)
[Link] (1 responses)
The way copy-n-paste works now on the Linux desktop is one of the worst features possible that users are exposed on Linux to on a regular basis. It's a chronically shit problem.
Hell if switching to Wayland means getting rid of the way X handles copy-n-paste buffers then that alone would be worth sacrificing X networking.
Posted Nov 9, 2010 13:29 UTC (Tue)
by nye (subscriber, #51576)
[Link]
(The other two are both related to window management; the design that has windows performing their own window management is, to put it politely, completely brain damaged.)
Posted Nov 7, 2010 19:58 UTC (Sun)
by iabervon (subscriber, #722)
[Link]
(Note, of course, that /dev/clipboard is a symlink to /proc/self/session/clipboard, which is a pseudo-device provided by the session manager for the session that a task belongs to, and the session manager's implementation of this device is responsible for handling exchanges like applications that see that the current clipboard content is a jpeg image, but ask for a bitmap, or see that something is formatted text and may ask for rtf or plain text. Also that the session manager is probably only acting as a directory for the clipboard manager to make itself known to clients. And I'm not going to get into how the clipboard manager needs to work, because I know that I don't know.)
Put another way: ICCCM is a de facto standard for this functionality and is an X standard, but the functionality actually has nothing to do with X. Any change away from X means that clients (or their toolkits) will have to change. Once they're changing, the right step is to do something that isn't particular to (e.g.) Wayland, because I want to copy/paste a URL from my TV to the IM client on my laptop by using my Android phone as a remote control (without interfering with the experience of the other people watching the TV, thanks). Obviously, that isn't going to just work immediately, but, when going to a new system for copy/paste, there shouldn't be any design limitations preventing it.
LPC: Life after X
Copy and paste is trival no matter how you do it, the only thing
needed is to let all programs agree on how to do it.
other ways of doing it.
LPC: Life after X
You must be joking
Oh, that's a great idea: if a user copies an image from his editing program and pastes it into his word processor, he gets hundreds of kilobytes of base64-encoded gunk? You clearly haven't thought through this problem. Any copy-paste system good for more than plain text requires type metadata.
You must be joking
You must be joking
> a simple text one at heart where the programs that want to support things
> like pictures do that by passing the needed information on in the form of
> text, and the complex data is just a temp file.
You must be joking
You must be joking
So much for edit buttons...
So much for edit buttons...
So much for edit buttons...
> 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.
> a user-interface point of view.
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...
You must be joking
You must be joking
> 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.
> 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?
> 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.
> *worse* while removing features at the same time.
You must be joking
Add a way to copy something multiple times in different formats, and let the program pasting it choose the type it prefers.
You must be joking
You must be joking
You must be joking
Simple is good enough
Simple is good enough
Simple is good enough
* 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.
Simple is good enough
Simple is good enough
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
Simple is good enough
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
Simple is good enough
> 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
Simple is good enough
Simple is good enough
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
Simple is good enough
Simple is good enough
> sake of arguing here, but rather because responding to the points you
> make forces me to think things through myself.
Simple is good enough
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.
Simple is good enough
You must be joking
http://blah/
file://blah/
sftp://blah/
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
Mouse selection and middle click paste
You must be joking
Content-negotiated. Rather than forcing everything into a lowest common denominator like plain text, the source app can offer various formats and the recipient chooses
Network transparent. So long as you actually do it with X (rather than sending a filename as per some suggestions in this thread) you get network transparency. Copy from the remote xterm, paste into the local web browser.
You must be joking
You must be joking
You must be joking
Apple Pasteboard and UTIs
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
2. Close out Gnome-terminal
3. Open up Gedit.
4. Middleclick to paste, then right click paste.
6. Close out firefox.
7. Attempt to paste text into Gedit.
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
a button on the browser bar that will clear the @#$% text when you press itYou must be joking
Konqueror has this, and I love it. That, the built-in site filtering, and the filebrowser are enough to keep me using konqueror rather than firefox.
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
You must be joking
A similar button does exist.
LPC: Life after X
LPC: Life after X
One of them is that I keep constantly trying to paste the primary selection before remembering that it doesn't exist. I don't think there's been a single day when I've not wished for that behaviour (there are programs that attempt to implement it, but it seems it's not really possible to to correctly).
LPC: Life after X