GNOME Bugzilla – Bug 78638
Incorrect X clipboard handling in Gnumeric
Last modified: 2004-12-22 21:47:04 UTC
I wrote several emails to gnumeric-list about this without anyone even saying "What are you talking about?", so I guess I had better file a bug. Everyone (and I mean everyone, Emacs 21, GTK+ >= 1.0 and GNOME, Qt >= 3.0 and KDE, Motif 2, Mozilla, the list is endless...) has agreed to do what it says in JWZ's wise description of X selections. http://www.jwz.org/doc/x-cut-and-paste.html Gnumeric doesn't do this. It should. Because X clipboard selections are copied and sent only on demand this does not increase the work done inside Gnumeric significantly for selections OR for the cut/copy/paste operations. You may elect not to assert PRIMARY when the user selects a single cell (or perhaps even when they select multiple cells) because most users associate the PRIMARY selection solely with text selections (although it is not defined in that way). That's up for discussion. Changing cut/copy/paste to use CLIPBOARD is vitally important for consistency between software, hence the severity of this bug.
If you would explain what you are looking for, perhaps you would get a better response. To me it seems that you are asking for some further feature which you claim gnumeric is missing. Whetehr or not you feel that it is very important or not, that is an enhancement request.
on further reading I am wondering whetehr this should even be closed: If I select text in gnumeric, switch to emacs and middle-click, the text is pasted. That tells me that gnumeric handles primary selections. If I copy a cell in gnumeric and then paste into emacs, the content of the cell is being pasted, that seems to mean that gnumeric handles the clipboard. oh, since development of enhancements takes place in the the cvs head branch, that's what I used to try it out. Please let us know whether I understood your request correctly.
OK, once more, with feeling. Gnumeric is an X application. X11 has these things called Selections. For our purposes there are two of them, PRIMARY and CLIPBOARD. Still with me? Gnumeric uses some GTK+ widgets for text entry. These were written by people who understand X11 and they use PRIMARY correctly to report their current selection. Those are fine, leave them alone. Gnumeric itself never sets the CLIPBOARD selection, even when the user does an explicit Edit/Cut or Edit/Copy operation. This is wrong. Instead it sets the PRIMARY selection, which probably should have been set when the user actually made the selection. Gnumeric doesn't look in the CLIPBOARD selection at all when the user pastes something with Edit/Paste. Instead the current selection in PRIMARY is used, which is wrong. That should only be used for the "middle-click paste" or an analagous operation. AFAIK Gnumeric is the only significant piece of X11 software which still gets this wrong (the Qt 2.x bug is fixed in Qt 3.0) So, pretty please with sugar on top, fix it. First of all go through the clipboard code and replace references to the PRIMARY selection with the CLIPBOARD, because I think that's 90% of the fix right there. Once you have that feel free to open an RFE to add whatever icing seems appropriate (e.g. middle click paste) Hints for testing using only common X11 tools: 1. You can see the contents of CLIPBOARD in xclipboard, and change them by just editing it directly in xclipboard. 2. You can set PRIMARY by making a selection in a (genuine) xterm and of course middle-button-paste will paste PRIMARY into it.
"The clipboard is broken" is a bug. "It would be nice if the clipboard worked properly" is a polite bug. "I think Gnumeric should support content-negotiation for clipboard paste operations" is an enhancement Put another way, if *I* think Gnumeric shouldn't do something that's an enhancement, but if the ICCCM, the Freedesktop group and all the widget toolkit developers say Gnumeric mustn't do it then it's a bug. This is a bug, it makes users think Gnumeric and/or their other applications are broken, or worse it makes them think X11 itself is broken. Severity = major.
Created attachment 7709 [details] [review] Small patch
The attached patch to cvs head solves the above issue. The problem with this patch is that it also disables copy/paste between older version of gnumeric and patched versions, since the patch version does not use PRIMARY.
1) We can't make that kind of switch until we have a better solution for inter-version gnumeric copy-n-paste. 2) We already support content negotiation, and intend to add more types of supported content.
1) What might that better solution look like? This is a standards compliance bug, it's completely orthogonal to any plans to change the form of the selection contents because it concerns only compliance to the ICCCM clipboard rules. It breaks interop because older Gnumeric versions got the rules wrong. ** 2) I know that Jody, it was just an example! ** As I wrote in private mail to Andreas, after the above patch is applied you can mostly restore interop by doing some additional work to handle PRIMARY selections as they were originally intended.
Jody, this seems to be one of those cases of "should we do A or B". It would be very simple to make this depend on a configuration setting so that users can choose their poison. It would also allow for more graduate move.
We need an answer to the inter version transfer. I don't know what shape that will take just now. I'll consider it shortly. 1 possibility is to make this change in 1.0.7. We are within our rights to request that people use the latest stable release. By it is not a step taken lightly.
I think we shouldn't touch the 1.0.x series at all. In the 1.1.x and later what I would like to see corresponds to what Nick indicated: copy/paste uses CLIPBOARD while select/middle-button-click uses PRIMARY that's why I propose that we make copy/paste for the moment configurable in 1.1.x so that we can have people try it with other apps and at the same time or shortly thereafter implement the "select/middle-button-click uses PRIMARY".
Configurability at this level is likely to just confuse people. I'm also learly of using 1.0 vs 1.1 as the place to make such a split. There will be good reason to have 1.0 and 1.2 on some systems, killing interoperability seems questionable. Sadly using PRIMARY the same way a terminal does makes little sense. In a spreadsheet there is ALWAYS a selection, we'd end up irritating the hell out of people.
I would love to be able to select and then just middle click to paste, but: perhaps we are looking at this the wrong way. We have 2 things: copy and paste. For copy, we should copy to both primary and clipboard. Since copy would require a selection anyways this probably fits with what other applications do de-facto. This also has no compatibility issue with older versions, but in the long term will help solve the compatibility issue for paste too. Then we only have to look at paste. For starters we could introduce a paste-x-clipboard.
A partial fix has been committed to cvs head: "copy" sets both the primary and clipboard selection. (This behaviour is similar to most X applications sinceeeeee setting the clipboard selection normally is preceded by setting the primary selection.) "paste" still only uses the PRIMARY selection. This fix does not affect compatibility between differnet versions of gnumeric since the clipboard selection is simply ignored, but may make it pssible at a later date to move to the requested clipboard handling. Since the clipboard selection is set, data transfer from gnumeric to any other X application should now work as expected.
After some consideration the result is as follows 1.0.x will paste from PRIMARY but will offer content on PRIMARY and CLIPBOARD 1.1.x will paste from CLIPBOARD but will offer content on PRIMARY and CLIPBOARD not perfect since older versions of 1.0 will be unable to interoperate with 1.1 but we're within our rights to request an upgrade with 1.0.