| |||||||||||||
You must be jokingYou must be jokingPosted Nov 7, 2010 3:51 UTC (Sun) by zander76 (guest, #6889)In reply to: You must be joking by i3839 Parent article: LPC: Life after X
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
(Log in to post comments)
You must be joking Posted Nov 7, 2010 4:06 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
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]
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 (✭ supporter ✭, #313) [Link]
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]
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 (✭ supporter ✭, #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]
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]
> 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 (subscriber, #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]
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.
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 (subscriber, #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]
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 (✭ supporter ✭, #313) [Link]
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]
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 (subscriber, #31333) [Link]
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.
Notice how you have 2 copy-n-paste buffers. Highlighting text makes the first buffer go away and be replaced by new text. This makes it almost entirely worthless for anything except working with a terminal. Using middlelick copy is one of those habits I wish I can break myself from doing.
The second buffer works in a sane way.
Almost.
5. Open up firefox. Highlight some text, Right click copy.
Notice something wrong?
The only people that get it right are Gnome apps that religiously follow the HIG. Probably KDE-only apps get it right, too. Everybody else gets it wrong almost every single time. Some apps will clear everything out every time. Some apps will override one buffer with another in order to be helpful. All sorts of really weird and crappy behavior.
It's something that is fundamentally broken with X and has been since the beginning of time. I don't think there is any sane way to fix it as nobody has been able to do so. Even with aggressive clipboard managers it's still a bit hit or miss if it works sometimes.
You must be joking Posted Nov 7, 2010 5:05 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]
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 (subscriber, #31333) [Link]
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]
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 (✭ supporter ✭, #313) [Link]
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]
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 (✭ supporter ✭, #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] a button on the browser bar that will clear the @#$% text when you press itKonqueror 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 (subscriber, #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 (guest, #40338) [Link]
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]
... 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 (subscriber, #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 (guest, #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.
|
|||||||||||||