LPC: Life after X [LWN.net]

LPC: Life after X

Posted Nov 6, 2010 19:30 UTC (Sat) by PO8 (guest, #41661)
In reply to: LPC: Life after X by i3839
Parent article: LPC: Life after X

"Copy and paste is trivial no matter how you do it."

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.

to post comments

You must be joking

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

Sorry, no, it really is trivial. And I'm not talking about ICCCM or any other existing implementations, just if you were to start a new one from scratch, as is the case for Wayland.

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.

You must be joking

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

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

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

Sorry for not making myself not clear enough:

> 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.

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?

You must be joking

Posted Nov 6, 2010 20:48 UTC (Sat) by quotemstr (subscriber, #45331) [Link] (34 responses)

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.

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.

You must be joking

Posted Nov 7, 2010 3:51 UTC (Sun) by zander76 (guest, #6889) [Link] (33 responses)

Hmm, it does *seem* like an easy problem to solve. Heres what was my first thought and I am sure I am missing something :)

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

You must be joking

Posted Nov 7, 2010 4:06 UTC (Sun) by dlang (guest, #313) [Link] (14 responses)

this sounds like it would be a perfect article for lwn, how a problem can see so simple and when you dig down it gets to be so hard.

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)

You must be joking

Posted Nov 7, 2010 4:30 UTC (Sun) by zander76 (guest, #6889) [Link]

Someone once asked me "What is a camel?". The answer was "An over designed mouse created by a committee!". It take a lot of *what ifs* to get from a mouse to a camel.

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 :)

You must be joking

Posted Nov 7, 2010 4:55 UTC (Sun) by PO8 (guest, #41661) [Link] (11 responses)

I've put some initial notes [on my blog](http://fob.po8.org/node/512). I'm not sure how many of the "dead-ends" I've covered, but I've at least tried to describe some reasons why the problem is so hard.

Hope this helps.

You must be joking

Posted Nov 7, 2010 7:53 UTC (Sun) by dlang (guest, #313) [Link] (7 responses)

from my naive point of view, the obvious answer to some of the problems on X would be to merge the two existing mechanisms, not eliminating either of them, but just having them both use the same clipboard storage so no matter how you copy something, either approach to pasting will produce the same result.

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 :-)

You must be joking

Posted Nov 8, 2010 6:08 UTC (Mon) by mfedyk (guest, #55303) [Link] (4 responses)

if you merged the two clipboards, you would have the problem of overwriting the current clipboard contents by accidentally selecting something with the mouse.

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

You must be joking

Posted Nov 8, 2010 7:16 UTC (Mon) by dlang (guest, #313) [Link]

the question is would that be worse than the confusion of having two clipboards and the inconsistent way that applications use one or the other?

You must be joking

Posted Nov 8, 2010 15:43 UTC (Mon) by foom (subscriber, #14868) [Link] (2 responses)

If you're using the menus to copy&paste on other platforms, you're doing it wrong. Use the keyboard shortcuts...

You must be joking

Posted Nov 8, 2010 21:39 UTC (Mon) by mfedyk (guest, #55303) [Link] (1 responses)

> If you're using the menus to copy&paste on other platforms, you're doing it wrong. Use the keyboard shortcuts...

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.

Mouse selection and middle click paste

Posted Nov 11, 2010 16:10 UTC (Thu) by cdmiller (guest, #2813) [Link]

I too use the mouse selection/paste extensively day to day. In fact it is seen as a "killer feature" by many folks when I'm convincing them to try a Linux desktop. Occasionally an application intentionally break this functionality. I remove those from my desktop and our computer labs whenever possible...

You must be joking

Posted Nov 8, 2010 13:32 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (1 responses)

There aren't two clipboards.

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.
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.

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.

You must be joking

Posted Nov 18, 2010 9:45 UTC (Thu) by renox (guest, #23785) [Link]

>> 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 <<

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.

You must be joking

Posted Nov 7, 2010 11:20 UTC (Sun) by quotemstr (subscriber, #45331) [Link]

Thanks for taking the time to write that up. It's a great summary of the issues that make the problem an involved one.

You must be joking

Posted Nov 7, 2010 13:58 UTC (Sun) by foom (subscriber, #14868) [Link] (1 responses)

You wrote:

> 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...

Apple Pasteboard and UTIs

Posted Nov 8, 2010 7:52 UTC (Mon) by PO8 (guest, #41661) [Link]

Interesting! Thanks much for the pointers.

You must be joking

Posted Nov 7, 2010 7:02 UTC (Sun) by mfedyk (guest, #55303) [Link]

+ 1

yes, very much looking forward to this article.

You must be joking

Posted Nov 7, 2010 4:08 UTC (Sun) by dlang (guest, #313) [Link] (17 responses)

a simple example of how you can run into problems.

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.

You must be joking

Posted Nov 7, 2010 4:13 UTC (Sun) by zander76 (guest, #6889) [Link] (1 responses)

Yeah, windows is really annoying with how they do it. They simply encode return characters at the end of every line in the terminal and not the actual return characters in the terminal text.

You must be joking

Posted Nov 7, 2010 4:35 UTC (Sun) by zander76 (guest, #6889) [Link]

The question leads me back to my original question which is "Does the application know how to copy and paste to itself". In the windows case it doesn't encode the text correctly right from the very beginning and has nothing to do with the system wide copy/paste function.

You must be joking

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

I am sure that everybody here is aware of this, but I just like to point it out time to time to remind everybody. It's like trying to explain how Windows 98 sucked to people that used Windows 98 for 7 years or more... they often don't realize how crappy something is because they have lived with it and avoiding it's problems has become second nature.

In Linux on Gnome:

1. Open up Gnome-terminal. Highlight some text and right click, select copy. Highlight some other text.
2. Close out Gnome-terminal
3. Open up Gedit.
4. Middleclick to paste, then right click paste.

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.
6. Close out firefox.
7. Attempt to paste text into Gedit.

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.

You must be joking

Posted Nov 7, 2010 5:05 UTC (Sun) by dlang (guest, #313) [Link] (13 responses)

the ability to highlight text and then middle click to paste is one of the things that I love about linux, not just when working with terminals (I paste things from webforms, pdfs, etc into webforms and applications all the time.

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.

You must be joking

Posted Nov 7, 2010 13:51 UTC (Sun) by drag (guest, #31333) [Link] (12 responses)

Yeah. I used to feel that way also. But since then I've changed my mind. Using middleclick is impossible to use if you want to perform a 'replace' on some text.

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.

You must be joking

Posted Nov 8, 2010 2:46 UTC (Mon) by madscientist (subscriber, #16861) [Link] (11 responses)

Yes but the answer to the browser bar problem is NOT to destroy the incredibly useful cut/paste behavior of traditional X. Rather, it's simply to have a button on the browser bar that will clear the @#$%& text when you press it, without requiring you to select the text first. How hard is that? I can't believe it's 2010 and we still don't have that as a default part of the browser.

You must be joking

Posted Nov 8, 2010 3:39 UTC (Mon) by dlang (guest, #313) [Link] (2 responses)

my work-around is to just open a new tab to paste the URL into (and a history of doing this is why I have a couple hundred tabs open :-)

You must be joking

Posted Nov 8, 2010 7:07 UTC (Mon) by mp (subscriber, #5615) [Link] (1 responses)

In Firefox middle-clicking anywhere in the window opens the URL from the selection, no need to open new tabs and aim at the tiny address bar.

You must be joking

Posted Nov 8, 2010 7:14 UTC (Mon) by dlang (guest, #313) [Link]

that's a configurable option. I don't remember when I first ran into it, but I hunted down how to disable it and have happily used the middle mouse button to open a link in a new tab instead (I got _so_ annoyed at slightly missing a link or text bar and the entire page disappearing on my when firefos opened some random URL that it thought I wanted to go to, or a search for the text that happened to be in the clipboard)

You must be joking

Posted Nov 8, 2010 3:54 UTC (Mon) by sfeam (subscriber, #2841) [Link] (1 responses)

a button on the browser bar that will clear the @#$% text when you press it
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

Posted Nov 8, 2010 15:53 UTC (Mon) by jackb (guest, #41909) [Link]

There is a Firefox addon called Clear Fields that adds the functionality you are looking for.

You must be joking

Posted Nov 8, 2010 8:56 UTC (Mon) by nicooo (guest, #69134) [Link]

I works fine with opera. X can't be blamed for people designing broken programs.

You must be joking

Posted Nov 9, 2010 5:20 UTC (Tue) by njs (subscriber, #40338) [Link] (2 responses)

AFAICT Firefox has an interesting tweak to this -- Control-L selects the text in the URL bar, *without* claiming the PRIMARY selection (which selecting the same text with the mouse would do). So to paste the PRIMARY selection into the current tab's URL bar, one can use the sequence: Control-L, backspace, middle-click.

You must be joking

Posted Nov 14, 2010 4:57 UTC (Sun) by tnoo (subscriber, #20427) [Link] (1 responses)

... which is exactly why I hate using FF. Konqueror has a "delete" button to rub out the old URL.

You must be joking

Posted Nov 14, 2010 6:10 UTC (Sun) by bronson (subscriber, #4806) [Link]

In FF just middle-click the favicon to the left of the URL. Instead of taking 2 clicks, it takes a single click.

Seems a rather weak reason to hate a browser.

You must be joking

Posted Nov 15, 2010 16:24 UTC (Mon) by wookey (guest, #5501) [Link]

ctrl-U used to provide this vital feature and then some eejit decided that that in a browser that should open a window with the page source in it. That was _such_ a painful decision and still enrages me on a daily basis on machines where I haven't persuaded the system to change the keybinding. (where did it come from?).

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.

A similar button does exist.

Posted Nov 18, 2010 3:52 UTC (Thu) by gmatht (subscriber, #58961) [Link]

In Google-Chrome middle-click the (+) new tab button to open a new window with that URL, this also works for searches.

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.