Gnome Developers Re-Implement Middle-Click Paste(news.softpedia.com)
news.softpedia.com
Gnome Developers Re-Implement Middle-Click Paste
http://news.softpedia.com/news/GNOME-Developers-Re-Implement-Middle-Click-Paste-380352.shtml
7 comments
I don't consider middle-click paste a quirk but rather a very useful feature I find myself missing all the time when I'm on Windows.
The bug in my humble opinion is having separate "selection" and "clipboard" buffers, but I just use a small util in the background to always keep both synchronized.
By the way, do people really use drag-n-drop on a daily basis? The few times I need to use that (mostly on windows) it's a really painful and awkward operation. You have to select what you want, click, then find the target (possibly minimized or hidden or something) and then drop at the right position while maintaining the mouse button pressed all the while. That's pretty terrible user experience as far as I'm concerned, but maybe I'm just doing it wrong/not used to it.
The bug in my humble opinion is having separate "selection" and "clipboard" buffers, but I just use a small util in the background to always keep both synchronized.
By the way, do people really use drag-n-drop on a daily basis? The few times I need to use that (mostly on windows) it's a really painful and awkward operation. You have to select what you want, click, then find the target (possibly minimized or hidden or something) and then drop at the right position while maintaining the mouse button pressed all the while. That's pretty terrible user experience as far as I'm concerned, but maybe I'm just doing it wrong/not used to it.
Still, I like the Windows idea that everything on the middle-mouse is related to navigating the viewport - scrollwheel, drag the view, etc. This consistency is pleasant.
While I love the convenience offered by the Linux selection-clipboard, it seems to mess with the design-language of the mouse. Maybe the Gnome team could keep the feature but move it to a new mouse action?
Moving the selection-paste to Meta+Lclick would get my vote. Would be a little bit painful transition, but would keep the feature while freeing up the middle-click for a role more consistent with its other functions.
And yeah, inter-app drag-and-drop is nightmarish because it's so hard to switch-tasks and scroll to the target without releasing the mouse. It's just not a useful interaction and 90% of the time I drag-and-drop something on Windows it's accidental anyways - it's a feature that belongs in a dustbin.
While I love the convenience offered by the Linux selection-clipboard, it seems to mess with the design-language of the mouse. Maybe the Gnome team could keep the feature but move it to a new mouse action?
Moving the selection-paste to Meta+Lclick would get my vote. Would be a little bit painful transition, but would keep the feature while freeing up the middle-click for a role more consistent with its other functions.
And yeah, inter-app drag-and-drop is nightmarish because it's so hard to switch-tasks and scroll to the target without releasing the mouse. It's just not a useful interaction and 90% of the time I drag-and-drop something on Windows it's accidental anyways - it's a feature that belongs in a dustbin.
> The bug in my humble opinion is having separate "selection" and "clipboard" buffers, but I just use a small util in the background to always keep both synchronized.
i actually appreciate this, because somteimes I really do want to copy something, do some other things, and then paste. Can't have the selection buffer overwriting the clipboard buffer.
> By the way, do people really use drag-n-drop on a daily basis? ... while maintaining the mouse button pressed all the while.
Agreed, especially in the age of the trackpad, on which drag and drop is far more difficult.
i actually appreciate this, because somteimes I really do want to copy something, do some other things, and then paste. Can't have the selection buffer overwriting the clipboard buffer.
> By the way, do people really use drag-n-drop on a daily basis? ... while maintaining the mouse button pressed all the while.
Agreed, especially in the age of the trackpad, on which drag and drop is far more difficult.
Your mileage may vary. I've never been a drag and drop sort of fellow, but I did start using three-finger swiping to move tabs around in my browser when that feature was introduced.
I use drag-n-drop all the time when I'm going through my photos. I open the memory card's picture directory in XnView, and with the directory browser on the left and a large preview on the right, I go through the pics and drag the "bad ones" into the trash.
I actually made a program to help automate the task, and it used the keyboard, but I always end up using XnView and drag-n-drop anyway.
I actually made a program to help automate the task, and it used the keyboard, but I always end up using XnView and drag-n-drop anyway.
> the Wayland graphics server doesn't have the notion of separate "selection" and "clipboard" shared-data.
I was almost warming up to the mess that is Wayland (though I still think "fixing X {server,extensions,whatever}" is a better idea). A decent case had been made that some areas (pixmap handling? already-client-side font stuff?), were in need of replacement.
Getting rid of "selection". though? WHY?! Compared everything else X does, it's not some performance concern. It is not even that complicated of a feature.
This, along with the bizarre "nobody uses X11 remotely" nonsense that is usually said when wayland is discussed is starting to smell like a microsoft-style "Not Invented Here" syndrome.
sigh
Selection-copy was the most important "required feature" for me, next to network transparency. If they are also messing with virtual desktops or few other minor window manager features, I guess I'll be staying with the version of x.org I am currently running. to go alongside my already-very-old windowmanager (E16).
I was almost warming up to the mess that is Wayland (though I still think "fixing X {server,extensions,whatever}" is a better idea). A decent case had been made that some areas (pixmap handling? already-client-side font stuff?), were in need of replacement.
Getting rid of "selection". though? WHY?! Compared everything else X does, it's not some performance concern. It is not even that complicated of a feature.
This, along with the bizarre "nobody uses X11 remotely" nonsense that is usually said when wayland is discussed is starting to smell like a microsoft-style "Not Invented Here" syndrome.
sigh
Selection-copy was the most important "required feature" for me, next to network transparency. If they are also messing with virtual desktops or few other minor window manager features, I guess I'll be staying with the version of x.org I am currently running. to go alongside my already-very-old windowmanager (E16).
I was almost warming up to the mess that is Wayland (though I still think "fixing X {server,extensions,whatever}" is a better idea). A decent case had been made that some areas (pixmap handling? already-client-side font stuff?), were in need of replacement.
Wayland is actually much, much simpler than X11. Most desktop users actually don't care about network transparency -- they want a fast, smooth local display. Network transparency is not needed. Better to take it out, and provide an extension module for those who want it -- based on something like RDP which is much more efficient than X11.
Remember that the object for comparison here is a Mac, which presents a perfect tear-free composited display running at 60fps. Compared to that, the old clunky X desktop is difficult to go back to.
Can't we all just accept the idea that Mac OS X curbstomping every other desktop Unix in terms of market- and mind-share might mean Apple got right what everyone else got wrong? Command-X, Command-C, Command-V. They're always there, they always do the right thing. Oh, and the presence of a dedicated "Command" key is another Apple-ism we should have adopted; modern Linux, following the lead of Windows, uses Ctrl. Which is just wrong and silly because you frequently do want to send Ctrl-C to a console program -- so terminal emulators remap the clipboard commands to Ctrl-Shift-X, etc.... Whatever.
Desktop Unix, except for Mac OS X, is a mess. Doing anything but throwing it all out and starting from scratch, emulating the cleaner, superior model of Mac OS X is falling prey to the sunk-cost fallacy.
Wayland is actually much, much simpler than X11. Most desktop users actually don't care about network transparency -- they want a fast, smooth local display. Network transparency is not needed. Better to take it out, and provide an extension module for those who want it -- based on something like RDP which is much more efficient than X11.
Remember that the object for comparison here is a Mac, which presents a perfect tear-free composited display running at 60fps. Compared to that, the old clunky X desktop is difficult to go back to.
Can't we all just accept the idea that Mac OS X curbstomping every other desktop Unix in terms of market- and mind-share might mean Apple got right what everyone else got wrong? Command-X, Command-C, Command-V. They're always there, they always do the right thing. Oh, and the presence of a dedicated "Command" key is another Apple-ism we should have adopted; modern Linux, following the lead of Windows, uses Ctrl. Which is just wrong and silly because you frequently do want to send Ctrl-C to a console program -- so terminal emulators remap the clipboard commands to Ctrl-Shift-X, etc.... Whatever.
Desktop Unix, except for Mac OS X, is a mess. Doing anything but throwing it all out and starting from scratch, emulating the cleaner, superior model of Mac OS X is falling prey to the sunk-cost fallacy.
> wayland
See? That's what I mean by the Not Invented Here syndrome - no concern for existing use-cases, but it's important to reinvent everything anyway. "Most desktop users" don't have an any opinion on unix/linux/X at all, as thye use windows or OSX. So why is this group the only set of requirements worth of considering?
> Apple got right what everyone else got wrong?
LOL. Not even going to touch that nonsense.
> Oh, and the presence of a dedicated "Command" key is another Apple-ism we should have adopted.
Sorry, META is not the same thing as Control, and both are necessary. Control has an advantage (if you remap it to where it's supposed to be by swapping it with CapsLock) that you don't have to leave the home row.
> Command-X, Command-C, Command-V
I think you've mean C-k, C-y, M-y, as supported by a very large amount of unix/X software. Of course, you can change that to your M-x/M-c/M-v with ~/.inputrc of course.
> Desktop Unix, except for Mac OS X, is a mess.
Desktop unix works just fine. GNOME and KDE are a mess, of course, and the source of a lot the bloat and slowdowns that are seen.
See? That's what I mean by the Not Invented Here syndrome - no concern for existing use-cases, but it's important to reinvent everything anyway. "Most desktop users" don't have an any opinion on unix/linux/X at all, as thye use windows or OSX. So why is this group the only set of requirements worth of considering?
> Apple got right what everyone else got wrong?
LOL. Not even going to touch that nonsense.
> Oh, and the presence of a dedicated "Command" key is another Apple-ism we should have adopted.
Sorry, META is not the same thing as Control, and both are necessary. Control has an advantage (if you remap it to where it's supposed to be by swapping it with CapsLock) that you don't have to leave the home row.
> Command-X, Command-C, Command-V
I think you've mean C-k, C-y, M-y, as supported by a very large amount of unix/X software. Of course, you can change that to your M-x/M-c/M-v with ~/.inputrc of course.
> Desktop Unix, except for Mac OS X, is a mess.
Desktop unix works just fine. GNOME and KDE are a mess, of course, and the source of a lot the bloat and slowdowns that are seen.
http://www.phoronix.com/scan.php?page=article&item=x_wayland...
(Take note of the x remoting content).
The thing is, we don't really "use" X these days, it's more just a wrapper. Toolkits and direct rendering do most of the work, that used to be reserved for X. So Wayland was designed to cut out all the cruft, and make everything nicer.
I must admit, two clipboards can be nice, but a single clipboard is probably sufficient. Maybe we can copy-paste without requiring the original program to stay open.
(Take note of the x remoting content).
The thing is, we don't really "use" X these days, it's more just a wrapper. Toolkits and direct rendering do most of the work, that used to be reserved for X. So Wayland was designed to cut out all the cruft, and make everything nicer.
I must admit, two clipboards can be nice, but a single clipboard is probably sufficient. Maybe we can copy-paste without requiring the original program to stay open.
> Maybe we can copy-paste without requiring the original program to stay open.
Probably no, we will not be able to copy and paste without requiring the original program to stay open. If you think of plain text, yes, that can work. But what about images? In which format should they be stored? Who should take care of converting these images from the internal storage model (the one used in Gimp is quite strange, for example) into plain bitmaps? And what about rich text? How can I copy and paste a bold, red, Helvetica 16pt text? In which format will it be stored in the clipboard?
Copy and paste, in its modern form, requires some form of MIME type negotiation that, in turn, requires applications to be around to negotiate.
Probably no, we will not be able to copy and paste without requiring the original program to stay open. If you think of plain text, yes, that can work. But what about images? In which format should they be stored? Who should take care of converting these images from the internal storage model (the one used in Gimp is quite strange, for example) into plain bitmaps? And what about rich text? How can I copy and paste a bold, red, Helvetica 16pt text? In which format will it be stored in the clipboard?
Copy and paste, in its modern form, requires some form of MIME type negotiation that, in turn, requires applications to be around to negotiate.
> [href]
Seen it, and seen the talk[1].
> we don't really "use" X these days
GTK+ and QT do not use a lot of X, as they render all their widgets with (e.g.) libcairo.so and libpango-1.0.so that only treat X as a framebuffer. Unfortunately, projecting your own usage habits onto others is an easy trap to fall into.
For example, one minor data point, from my desktop system - I use the built-in font server:
/// that said ///
As I mention briefly, I was warming up to the idea of wayland. GTK+ and QT are certainly popular, and some things DO need to be fixed. The linked phoronix article (or talk) does bring up some good points. The massive amount of (serialized) round-trips to the x-server (even locally) that are mandated by the protocol is paticularly outrageous. If backwards compatibility and remoting can be maintained through some sort of extension (or whatever), then it could even be a nearly-seamless drop in.
The clipboard and selection, on the other hand, have nothing to do with any of that. They aren't a performance problem, and there is no reason to remove it. In fact, given this is a big change in general, and an opportunity to fix some of the core protocols, why not /expand/ the idea to include a full kill-ring or similar? Call it a fix for CUT_BUFFER[0-7] that were never really used?
Changing protocols and the display pipeline ("things programmers have to worry about") is one thing. Cutting UI features that have been in place for a long time ("things users care about strongly") is a different world entirely.
> but a single clipboard is probably sufficient
When you've used both for decades, a single buffer is NOT sufficient. They end up serving completely different purposes, and are often needed simultaneously.
[1]: http://www.youtube.com/watch?v=RIctzAQOe44 [2]: http://www.antigrain.com/research/font_rasterization/index.h...
Seen it, and seen the talk[1].
> we don't really "use" X these days
GTK+ and QT do not use a lot of X, as they render all their widgets with (e.g.) libcairo.so and libpango-1.0.so that only treat X as a framebuffer. Unfortunately, projecting your own usage habits onto others is an easy trap to fall into.
For example, one minor data point, from my desktop system - I use the built-in font server:
$ rdb -q | grep 'URxvt.*font'
URxvt*font: -xos4-terminus-medium-r-normal--14-140-72-72-c-80-iso10646-1
/// that said ///
As I mention briefly, I was warming up to the idea of wayland. GTK+ and QT are certainly popular, and some things DO need to be fixed. The linked phoronix article (or talk) does bring up some good points. The massive amount of (serialized) round-trips to the x-server (even locally) that are mandated by the protocol is paticularly outrageous. If backwards compatibility and remoting can be maintained through some sort of extension (or whatever), then it could even be a nearly-seamless drop in.
The clipboard and selection, on the other hand, have nothing to do with any of that. They aren't a performance problem, and there is no reason to remove it. In fact, given this is a big change in general, and an opportunity to fix some of the core protocols, why not /expand/ the idea to include a full kill-ring or similar? Call it a fix for CUT_BUFFER[0-7] that were never really used?
Changing protocols and the display pipeline ("things programmers have to worry about") is one thing. Cutting UI features that have been in place for a long time ("things users care about strongly") is a different world entirely.
> but a single clipboard is probably sufficient
When you've used both for decades, a single buffer is NOT sufficient. They end up serving completely different purposes, and are often needed simultaneously.
[1]: http://www.youtube.com/watch?v=RIctzAQOe44 [2]: http://www.antigrain.com/research/font_rasterization/index.h...
I love middle select too, I use it often !
Also can be used to work around copy-paste issues, or quickly copy pasting without formatting !
The other argument is that the conventional meaning is different. Drag and drop is universally a "cut and paste" operation. If I drag text I expect it to re-position where dropped. Select-and-middle-click is a "copy and paste" operation.
> Drag and drop is universally a "cut and paste" operation.
It changes to "copy and paste" if you keep the Ctrl key pressed. The cursor changes and adds a plus sign to indicate this.
So it is flexible in that regard.
It changes to "copy and paste" if you keep the Ctrl key pressed. The cursor changes and adds a plus sign to indicate this.
So it is flexible in that regard.
> Drag and drop is universally a "cut and paste" operation.
Unless the source is read-only. You can select text from the web and then drag-and-drop that selection into a text editor, and you won't change the web.
Unless the source is read-only. You can select text from the web and then drag-and-drop that selection into a text editor, and you won't change the web.
> Drag and drop is universally a "cut and paste" operation.
Unless you are using Gnome and the origin and destination of your drag and drop are on two different devices. In which case it will copy instead of cut.
Unless you are using Gnome and the origin and destination of your drag and drop are on two different devices. In which case it will copy instead of cut.
Not just Gnome. Windows is like that too.
This ambiguity means that I never use lclick-drag even when I'm tempted to use the clumsy operation - on windows I always RClick-drag so that the operation (move or copy) is explicitly selected.
Why fix if it ain't broke? I don't think this Wayland port is needed.
Would be better to spend engineering effort to add more features to GNOME and make the existing experience smoother.
Would be better to spend engineering effort to add more features to GNOME and make the existing experience smoother.
X-infterfaced Linux has been failing to make a dent in end user space for two decades. Non-X unices have been highly successful in end user space (various Aplle and Goodle offerings, not to mention set top boxes etc.)
I don't necessarily think Wayland is going to set the world on fire, but the urge to dump X is based on a solid inference.
I don't necessarily think Wayland is going to set the world on fire, but the urge to dump X is based on a solid inference.
There are too many factors at work to make that kind of broad statement. Correlation not causation etc. etc.
I think it's that kind of short sighted jumping to conclusions that brought us train wrecks like Windows 8 and Gnome 3. Someone looked around, noticed touch interfaces on iOS and Android devices were selling like hotcakes while traditional PC sales were slumping, and decided clearly the only logical conclusion is to put a touch based interface on a non-touch desktop computer.
You can have my mouse when you pry it out of my cold dead fingers, stay the hell away from my desktop experience.
I think it's that kind of short sighted jumping to conclusions that brought us train wrecks like Windows 8 and Gnome 3. Someone looked around, noticed touch interfaces on iOS and Android devices were selling like hotcakes while traditional PC sales were slumping, and decided clearly the only logical conclusion is to put a touch based interface on a non-touch desktop computer.
You can have my mouse when you pry it out of my cold dead fingers, stay the hell away from my desktop experience.
Not making any causal statement, just pointing out the correlation.
Unity and Gnome 3 don't actually remove the complexity of a multilayered X environment, they just selectively attempt to hide some of it from the user. I don't think that's a good solution either technically or from a UX perspective.
I'm writing this from MATE by the way.
Unity and Gnome 3 don't actually remove the complexity of a multilayered X environment, they just selectively attempt to hide some of it from the user. I don't think that's a good solution either technically or from a UX perspective.
I'm writing this from MATE by the way.
Well in fairness I'm not convinced that the issue is X, as much as the hordes of desktop environments developed on top of X.
But even without that, the currently-available DEs are good enough that if simple quality were the only thing holding Linux desktops back, they should be doing much better with market share. So I don't think that is the only issue.
But even without that, the currently-available DEs are good enough that if simple quality were the only thing holding Linux desktops back, they should be doing much better with market share. So I don't think that is the only issue.
X has a warm place in my heart and has ever since I first logged into my high school's SGI workstation that students Weren't Supposed to Use. However, the multilayering approach encouraged/required by X is a vector for an awful lot of subtle bugs and UX inconsistencies.
I don't think it's the only thing holding The Year of the Linux Desktop back, but successful end-user systems all have monolithic graphical user environments, and [GNU/X/]Linux has this bric-a-brac tower of Babel. Attempts to rationalize the tower post-hoc, even with extreme prejudice like Gnome 3, are going to be less effective than building from the ground up IMHO.
I don't think it's the only thing holding The Year of the Linux Desktop back, but successful end-user systems all have monolithic graphical user environments, and [GNU/X/]Linux has this bric-a-brac tower of Babel. Attempts to rationalize the tower post-hoc, even with extreme prejudice like Gnome 3, are going to be less effective than building from the ground up IMHO.
I know it's possible, but I honestly don't know how to copy between instances of vi without it. This has been a huge convenience for me and I'm glad they are keeping it.
I have these lines in my .Xresources file (which is sourced by .xinitrc with `xrdb -merge "${HOME}/.Xresources"`):
Shift<Key>Insert: insert-selection(CLIPBOARD) \n\ <Key>Insert: insert-selection(PRIMARY) \n\ Shift<Btn2Up>: insert-selection(CLIPBOARD) \n\ Shift<Btn1Down>: select-start() \n\ Shift<Btn1Motion>: select-extend() \n\ Shift<Btn1Up>: select-end(CLIPBOARD)
This way, if I select something with the mouse while pressing shift it will go to the clipboard. I can shift-select text on the terminal and paste to Firefox using ctrl-V, for example. And I can copy something from Firefox using ctrl-C and paste it on vim using shift-insert.
Normal selection goes to the other clipboard, so I can paste it using middle button or just clicking insert.
Shift<Key>Insert: insert-selection(CLIPBOARD) \n\ <Key>Insert: insert-selection(PRIMARY) \n\ Shift<Btn2Up>: insert-selection(CLIPBOARD) \n\ Shift<Btn1Down>: select-start() \n\ Shift<Btn1Motion>: select-extend() \n\ Shift<Btn1Up>: select-end(CLIPBOARD)
This way, if I select something with the mouse while pressing shift it will go to the clipboard. I can shift-select text on the terminal and paste to Firefox using ctrl-V, for example. And I can copy something from Firefox using ctrl-C and paste it on vim using shift-insert.
Normal selection goes to the other clipboard, so I can paste it using middle button or just clicking insert.
If you are using vim and it is built appropriately, the "* register reflects the contents of the primary selection and the "+ register the contents of the clipboard. See :help registers
You can also use the default register instead of "+
:set clipboard=unnamed
http://vim.wikia.com/wiki/Accessing_the_system_clipboard
:set clipboard=unnamed
http://vim.wikia.com/wiki/Accessing_the_system_clipboard
Ah, yes, I see that does work. I probably tried on a version that wasn't compiled with that- found middle-click and never looked back. Thanks though for getting me to check again.
There's something delightfully quaint about a world in which middle-click paste warrants a news article. :)
Caveats: - I'm amongst the folks rejoicing. :) - Yes, Apple products and Win8 sometimes attract similar attention to detail. - I recognise the technical context, too (see thristian's comment).
Still quaint. :P
Caveats: - I'm amongst the folks rejoicing. :) - Yes, Apple products and Win8 sometimes attract similar attention to detail. - I recognise the technical context, too (see thristian's comment).
Still quaint. :P
middle-click paste is so plainly useful that I often find myself completely baffled that other windowing environments haven't copied it.
Especially having two buffers is a productivity booster, if I would count how many times per day I take some data from a source window/view with ctrl+C and another one with selecting it, then pasting one of them with ctrtl+v and the other one at the correct position with middleclick it would be quite alot. Like I just did with this text. Then I have klipboard which keeps both of the buffers in a history, so awesome Im baffled how my collegues at windows can even do their job.
Especially useful in terminals where ctrl+shift+c/v is awkward to press compared to a middleclick.
Especially useful in terminals where ctrl+shift+c/v is awkward to press compared to a middleclick.
"The controversial desktop environment" .. things were not always thus. (gnome user since 0.9).
Hoooooray! Victory, at least for now...
Good work, Long life to Ubuntu-Gnome, my favorite desktop since Ubuntu introduced Unity.
Thank goodness! Middle click paste drives me crazy. ... Although i dont use gnome
I imagine there's a lot of resistance at the idea of including decades-old X11 quirks into the fresh, modern UI era, and I can totally understand that. The best argument I've heard for supporting something like it is to consider it an interruptible drag-and-drop operation. That is to say, in every scenario where you can select something then drag and drop it into another place, or another application, you should be able to select that thing then middle-click on the destination for exactly the same effect. The best argument for having this behaviour (at least as an option) is that it's more accessible than traditional drag-and-drop for users with certain mobility impairments, and fully-able users can use it to do things they can't normally do with drag-and-drop, like shuffle through windows to find the intended target. It also piggybacks on a lot of infrastructure (format negotiation, etc.) that needs to exist for drag-and-drop anyway, and lastly it makes old-school users happy. :)