Gnome Developers Re-Implement Middle-Click Paste
news.softpedia.com
news.softpedia.com
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. :)
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 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.
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.
Would be better to spend engineering effort to add more features to GNOME and make the existing experience smoother.
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.
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.
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 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.
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.
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.
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.
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.
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 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).
(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.
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.
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...
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.
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.
:set clipboard=unnamed
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.
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
Especially useful in terminals where ctrl+shift+c/v is awkward to press compared to a middleclick.