*** Bug 335221 has been marked as a duplicate of this bug. ***

After a recent addition to Freedesktop.org clipboard specification, GTK+ does not longer conform to it until this bug has been fixed.

See http://webcvs.freedesktop.org/icccm-extensions/selections/clipboards.txt

But 2) is wrong.
Applications shouldn't forget their selections behind the user's back.

But 2) is right.  If I make a selection from app A and then from app B, app A is supposed to delesect it; otherwise, how would I know which one I selected.  Think: select from A, select from B, go to lunch, return and prepare to paste - which one is it?  Open two xterms, select text in one, select text in the second, note that the selection in the first is no longer highlighted.

Also consider: I make a selection in application A and do whatever I want to do with it. Then I select something in application B and want to paste it into A.  Since A still has something selected, what should happen when I paste into A?  The selection from A? Or the new one from B?  Sorry, but I want B's selection to be pasted not A's.  Therefore, since A's selection is now invalidated, it should be unhighlighted.  And it isn't behind the user's back; the user told it to do it.

No, 2) is wrong.
The entire desktop metaphor is based on the idea that applications as separate entities.
If I do *anything* in app A, then that should not affect *anything* in app B.

There is indeed a problem in that there needs to be a way to mark the most recent highlight, and there's a bug open for this. But it might be that the whole concept of PRIMARY paste is not compatible with the modern desktop metaphor.

*** Bug 425343 has been marked as a duplicate of this bug. ***

Bug 425343 is my dupe of this one, Im DYING inside every time I have to use gedit :( Please do something with it.

In reference to comment #5: "If I do *anything* in app A, then that should not affect *anything* in app B."

If this is true, then you can not paste anything from app A into app B and vice versa.  2) is correct.

I don't follow your argument.
The clipboard is outside of applications. 

There's heaps of use cases why 2) is wrong. See Bug 334060.

OK, I have text selected in app A and app B.  I go to app C and paste; which do I get?

Note: I have not stated any order for when the A and B selections were made; I may not know.  The argument for PRIMARY is basically, "What I see (selected) is what I get."  Your argument seems to be, "Being nondeterministic means never having to say I'm wrong."

Well, you're wrong.

>OK, I have text selected in app A and app B.  I go to app C and paste; which do
>I get?

the LAST one you selected. Thats the way it works everywhere(?, or should :P).

That's the point, you can't always tell with the way GTK presents it.

Another scenario:
You select text, in order, from apps A, B, then C.  You paste in A; what do you get?  The PRIMARY selection from C or the LOCAL selection from A?  (I would say the PRIMARY selection.)

To make things more deterministic, something like the following should happen:
Last selected become PRIMARY (marked accordingly), all others either deselect (standard X method) or change the marking to LOCAL-only (e.g., outline or greyed out).
To make a LOCAL-only selection PRIMARY, some action is needed (e.g., single left click in the selected region).

I'd suggest not changing colors to indicate non-PRIMARY other than some shade of grey to avoid problems with colorblind entities (e.g., monochrome and greyscale monitors).

I don't have an issue with an app wanting to keep its selection, I just want it to be clear what's going to be used in another operation.

>I don't have an issue with an app wanting to keep its selection

I have
highlight something, fire up Gftp (oh god I hate this crashing crap)
yep, app just chose to highlight stuff it had in HOST window, I have to copy my stuff again or type it manually.

one more
fire up Gedit, load some shit, highlight a word, press ctrl-f, search window pops up and app decides for me (!!!! :/) to highlight the content of search input window, thats not bad in itselfe until you decide to select another word and paste it to search input window - try it, its fun .. :/

Quoth Don Koch: "Think: select from A, select from B, go to lunch, return and prepare to paste - which one is it?"

Do you really do this, or are you just being difficult?  I use PRIMARY a lot.  It's a good shortcut for a quick copy and paste.  But my time between selection and paste is never more than a few seconds.  I don't expect selections to stick around so I can paste them after lunch.  Given that we've had this overlapping windows technology since, oh, forever, it would probably take me longer to sift through all my applications looking for the selected text than it would to just go select that text again.

PRIMARY is a great little time saver for the minority of us that know and like it.  And as long as it doesn't get in anybody else's way, that's great.  But forgetting the selection is a serious usability problem that affects a lot of people, many of whom don't have the slightest clue what this PRIMARY mumbo jumbo is.

If we're unwilling to slightly bend our implementation from the specification (as, I might add, many X applications have done), then the only way to fix this usability problem is to drop support for PRIMARY.  And that would be a shame.

Here's the possible issues as I see it.

1) PRIMARY buffer should not be cleared when left clicking in a gtk text area <--this is the most annoying one and there's no reason this at least should be fixed

2) Where selections are automatically made by a gtk application, eg searchbox, it should not put the selection to PRIMARY.

GTK+ does not necessarily have to match traditional Xt/Xaw behavior but it would be good to have better compatibility.

When I use middle-click-paste to copy and paste within a document in, say Gedit, I like to left-click at my destination and see that the cursor has moved to the correct point, and *then* middle click, now that I know that my text is going to the right spot. Also, sometimes I need to type an open-paren or something before I paste. Unfortunately, neither of these is possible in Gedit or other applications that use the Gtk text area widget. (Incidentally, OpenOffice also behaves this way, but I doubt that OO uses the Gtk text widget.)

All of the above would be solved by compliance with that updated Freedesktop specification: http://webcvs.freedesktop.org/icccm-extensions/selections/clipboards.txt

----

However, there is another problem, that is *not* explicitly addressed by that specification: clobbering of the PRIMARY selection by automatically selected text. The relevant part of the clipboard spec is this: "selecting but with no explicit copy should only set PRIMARY." The question is, what constitutes the act of selecting? I would think that *only* something that is selected *manually* by the user should fit this definition. That means that any dialog that comes up with text pre-selected should *not* affect the PRIMARY clipboard. 

Examples of auto-selected things that clobber PRIMARY selection include:
* The default selection in a dialog, such as the find dialog in Gedit
* auto-complete text in the run dialog/file chooser dialog
* autoselection of the text in the location bar of a browser when the location bar is clicked
* any text field that autohighlights its contents when focused

The thing about all of these autoselections is that it's quite likely that I am opening the dialog/clicking in the text box so that I can middle click paste *my* text into them. If clicking in them automatically clobbers my selection, then middle click pasting into them is all but impossible. Having a "clear" button for a text box helps, but it's a workaround, not a fix.

The solution for this is, as mentioned above to only set the PRIMARY clipboard when the user *manually* selects text. This is simple in theory, but I realize that in practice that this is likely to be very difficult. It would require the selected text and the text that goes in the PRIMARY selection to be tracked separately, I suppose. It would really improve usability, though.

Looking to the future, if this were implemented, it would be a nice addition if middle clicking on such an autoselected piece of text would delete that text and replace it with the text to be pasted. This would match the behavior of control+V (i.e. overwriting selected text with clipboard). This way, I could really press control+F and then middle-click paste my text right into the dialog without pressing delete first to clear it.

Hello all,
I didn't know that there were philosophical issues behind what I consider being a bug in gedit .. And I apologize in advance for my quick-reading of the previous posts and for not caring enough about arguments.
Anyway, for me when 
1) LMB select a text in a console -> MMB paste in Gedit works
2) LMB select in Epiphany -> MMB paste in Gedit works
3) LMB select in a first Gedit tab -> MMB paste in another Gedit tab works
BUT
4) LMB select in a Gedit tab -> MMB paste in the same tab does not works,
Then, this sounds to me like an usability issue or a bug .. like something that should be corrected. At least the user should be provided with means to choose his prefered behaviours.

Regards,
Mathieu Petit

I want to point out that I've rewitten the clipboard specification
since the latest cvs version. I posted the specification to xdg list.
Follow-up discussions didn't bring up any problems in the new version.
Discussion participants requested that the old specification would be
kept available as it provides more background information and rationale,
than the new version which works more as a conformance definition for
toolkit developers.

While the specification has not yet been "officially" published by
Freedesktop.org it is already available in my original posting at
http://lists.freedesktop.org/archives/xdg/2007-June/008482.html

Conforming to it should fix most clipboard usability problems
for GTK+ users, including many worried users who found the
time to talk about the problem here.

From my understanding of the updated spec, Bug 334060 is also affected.

*** Bug 570562 has been marked as a duplicate of this bug. ***

Hi!

It's been more than three years since this bug was reported.  I've been hating this feature all along, thinking that it was something that someone had done on purpose, but only today have I found out that it's actually just a bug.

Not only is it extremely annoying, but there's a freedesktop specification that clearly states it's a bug.  Thus, I'm marking it as confirmed and raising the severity to "normal".

Is there any real reason why unselecting text removes the selected text from the PRIMARY clipboard?

I've been looking at the code, and though I can't yet say that I fully understand what's going on, it seems that it's done on purpose, i.e. it's not an omission, the information is actually being removed from the clipboard.

I'll look into the code a bit more, and maybe try to provide a patch, but if someone from the gtk devs could look into this, that would be great.

The bug exists because some old unix systems used selection as a visualization for the stuff currently in primary. For this to work it was also required that only one application at a time could have a selection. I guess the idea wasn't originally that bad. The one-to-one correspondence ought to be easy for users.

In modern days however, selections are used also for emphasizing parts of text, and many users select text just to keep track about what they are reading. Not to mention that the primary is in modern ages expected to be just an easter egg feature for power users. A one that should not be visible to an average user in any way.

"Clearing" primary at deselection time also makes it impossible to select cursor location before performing middle-click pasting, as this would clear the selection. This is compensated for by moving the cursor when the pasting happens, causing the behavior to be different from a terminal window where pasting will always happen at the cursor location. This causes errors for power users who tend to use terminal windows.

It has to be noted that selecting paste location with the same click that performs the paste has it's uses. However, performing series of true repetitive clicks is not too hard. So a user is still able to right-click, middle-click in a row by using two fingers for this.

In future it might make sense to support moving cursor with the past action trough some meta key. E.g. holding ctrl-key while middle clicking to paste at the mouse pointer location instead of the text cursor location.

(In reply to comment #23)
> The bug exists because some old unix systems used selection as a visualization
> for the stuff currently in primary. For this to work it was also required that
> only one application at a time could have a selection. I guess the idea wasn't
> originally that bad. The one-to-one correspondence ought to be easy for users.

I think "only one selection at a time, across the entire system, period" is the only sane behavior both for naive users and power users, *independent* of any discussion of PRIMARY vs CLIPBOARD, middle-mouse vs Ctrl-V, etc.  If there are two selections, how can you tell what a menu or keyboard command that operates on the selection will do?

> In modern days however, selections are used also for emphasizing parts of text,
> and many users select text just to keep track about what they are reading.

I don't see how this is relevant.

> Not to mention that the primary is in modern ages expected to be just an
> easter egg feature for power users. A one that should not be visible to
> an average user in any way.

I don't think it is necessary to be this strict about it, but in any case, I would argue that the existence of PRIMARY would become *less* visible if all of my suggestions in the original bug report were implemented.

The fd.o spec is difficult to read due to lack of word wrapping, but it appears to have dropped points (2) and (4) from my original proposal, which disappoints me.  Clearing the selection when an application loses PRIMARY is *essential* -- without it the system behaves in a way that a user cannot develop a coherent mental model of.  Setting PRIMARY whenever CLIPBOARD is set is nearly as important: it means that middle-mouse paste always applies to the most recent cut/copy action, whether that was implicit via selection or explicit.

I suspect you don't like those points because you are thinking of PRIMARY and CLIPBOARD as separate entities, where CLIPBOARD is the normal thing for people to use and PRIMARY is this secret feature for "power users".  That's the wrong way to think about it.  The right way to think about it is, there's one "clipboard" but it has increasingly transient "views": CLIPBOARD (only set by explicit commands), PRIMARY (set by explicit commands *and* by explicit selection), and the visible highlight (set by keyboard traversal as well as the above two).

From that + the desired paste behavior (Ctrl-V for CLIPBOARD, middle-mouse for PRIMARY) you can deduce all of the requirements in my original post, and you should be able to see why all of them are *requirements*.

> "Clearing" primary at deselection time also makes it impossible to select
> cursor location before performing middle-click pasting, as this would clear the
> selection. This is compensated for by moving the cursor when the pasting
> happens, causing the behavior to be different from a terminal window where
> pasting will always happen at the cursor location. This causes errors for power
> users who tend to use terminal windows.
> 
> It has to be noted that selecting paste location with the same click that
> performs the paste has it's uses. However, performing series of true repetitive
> clicks is not too hard. So a user is still able to right-click, middle-click in
> a row by using two fingers for this.
> 
> In future it might make sense to support moving cursor with the past action
> trough some meta key. E.g. holding ctrl-key while middle clicking to paste at
> the mouse pointer location instead of the text cursor location.

These paragraphs do not make very much sense to me, and to the extent that they do, they appear to be irrelevant to the discussion.

> These paragraphs do not make very much sense to me, and to the extent that they
> do, they appear to be irrelevant to the discussion.

Following up to myself, this was slightly unfair, I see now that the first of those paragraphs is giving a rationale for rule 3 (do not drop PRIMARY when the visible highlight is cleared) -- but I was under the impression that everyone agreed on that part, and the remaining debate was about rules 2 and 4.

*** Bug 548492 has been marked as a duplicate of this bug. ***

Zack:

If everyone agrees that clearing the clipboard when unselecting is a bug, is there a way to push at least that part of this bug into getting solved?

I've been trying to fix the code, but I wasn't yet able to do it.  From reading the comments I'm quite certain that it is done on purpose:

  /* may have deleted the selection... */
  update_selection_clipboards (buffer);

And the like.

But my quick hack didn't work, I'll need to get more familiar with the code to fix it.

(In reply to comment #27)
> If everyone agrees that clearing the clipboard when unselecting is a bug, is
> there a way to push at least that part of this bug into getting solved?

I'm just a user wrt Gtk/GNOME... perhaps splitting that part out to a separate bug and citing the fd.o spec would be a way to get developer attention on it?

> I think "only one selection at a time, across the entire system, period" is the
> only sane behavior both for naive users and power users, *independent* of any
> discussion of PRIMARY vs CLIPBOARD, middle-mouse vs Ctrl-V, etc.  If there are
> two selections, how can you tell what a menu or keyboard command that operates
> on the selection will do?

I'm pretty sure a menu item in gedit isn't going to act on some text I have selected in Abiword.  If that confuses anybody, well, we have far more basic user training issues we have to address.

The only time it might be slightly confusing is when there are multiple text views in a single window.  In cases where there might be ambiguity, I would expect menu items to affect whatever has keyboard focus.  The same way you know which text view your backspace key will delete a character from.  The same way applications handle similar potential ambiguity with list views, which do not share the selection-losing behavior of text views.

> Clearing the selection when an application loses PRIMARY is *essential* --
> without it the system behaves in a way that a user cannot develop a coherent
> mental model of.

Really?  I think you mean they can't develop *your* mental model of it.  No other system I know of drops selections.  Chances are good that affected users, by and large, won't even understand the cause of their dropped selection.

You are framing this by the implementation details of what you're used to.  That is not a good way to do user-centric design.

> I suspect you don't like those points because you are thinking of PRIMARY and
> CLIPBOARD as separate entities, where CLIPBOARD is the normal thing for people
> to use and PRIMARY is this secret feature for "power users".  That's the wrong
> way to think about it.  The right way to think about it is, there's one
> "clipboard" but it has increasingly transient "views": CLIPBOARD (only set by
> explicit commands), PRIMARY (set by explicit commands *and* by explicit
> selection), and the visible highlight (set by keyboard traversal as well as the
> above two).

I disagree entirely.  I think of them as completely separate things.  I encourage others to do the same.  Thinking of PRIMARY as some view of the clipboard just leads to very confused comments from inadequately clued users.  I've seen the comments again and again.  The only thing PRIMARY and the clipboard have in common is that they both use X selections.  And that's a really boring implementation detail.

*** Bug 580431 has been marked as a duplicate of this bug. ***

I'm interested in this bug too.
 Margarita Manterola: what workaround did you try that does not work?

You do not want to combine copy that happens by explicit actions and copy that
happens by mere selection. The reason is that there will always be users who
are not aware of the implicit copy feature. At some point one of them will make
an explicit copy action, then he will select some text just to help him read
it, and in the end he will be amazed why the following explicit paste action
does not paste the thing he "actually" copied, but just some random text that
he was reading a while ago.

(In reply to comment #31)
> I'm interested in this bug too.
>  Margarita Manterola: what workaround did you try that does not work?
> 

My workaround was in code, I found that when calling update_selection_clipboards in gtktextbuffer.c, if nothing was selected, gtk_clipboard_clear was called.  I commented out that call and a similar one in gtk_text_buffer_remove_selection_clipboard, but it still won't paste after removing the selection.

So, there's something else.  The code of gtktextbuffer is not bad, but it's complicated and not easy to understand it out of the blue.  I'll keep hacking at this, hoping to find something.

I'm confident, however, that any of the gtk devs would find the solution much faster.

Toni, I don't think anybody is proposing that setting PRIMARY should also claim the clipboard.  That's terribly broken.  XChat does that (or at least did as of FC6), and it's very annoying.

What's proposed (point 4) is that claiming the clipboard also claims the PRIMARY selection.  Usually, this happens anyway, because you have to select something to copy it.  But there are cases where you copy something without a selection, such as copying a link address through the link's context menu.

I don't have any gripes with that, except that claiming PRIMARY currently deselects anything you might have selected in another application.  Unless that changes (which is what I'm arguing for), you would have your selections dropped because you did something which, to normal people, is completely unrelated.  It's confusing.

Couldn’t one make two bugs of this? That would allow to concentrate on fixing the “deselection clears PRIMARY” issue in one place and discussing the “PRIMARY deselects and CLIPBOARS sets PRIMARY” in another. Some duplicates have been closed that don’t care about general concepts but rather complain about PRIMARY being cleared, so I think there is some interest in getting this particular issue solved.

Frederik, you're right, of course.  Bug 334060 already exists for the issue of losing the selection when PRIMARY is lost, which is what I've mostly commented on.  Any further discussion about that topic should happen there.  I'll make a note on that bug to read the backlog on this bug.

Yes, splitting each of the points to its own bug seems sensible to me.  I've filed bug 584233 about point (4); let's make this bug just be about point (3).

I argued strongly for (2) above, but on reflection I would give up (2) to get (4).  (4) actually makes me do extra work, after all.  And it seems like people are really attached to multiple visible selections, bizarre as that seems to me.

Actually, there's been enough noise in this bug that I think separating both of the points that might reach consensus quickly is a good idea. I've filed bug 584236 for point (3) and will now make this bug depend on all three.  I hope we can get (3) and maybe even (4) done and leave the argument about (2) to bug 334060.

Here is a version of the clipboard specification with line breaks. The content should be equal to the spec I posted on Freedesktop.org mailing list.

http://iki.fi/toni.ruottu/projects/clipboard-spec.txt

*** Bug 746130 has been marked as a duplicate of this bug. ***

We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.

Yes, this bug is still important to me and still relevant with the current version of GTK+.  I do not have the necessary bugzilla privileges to clear the NEEDINFO state.

afaics, this is obsolete, as the other 2 bugs were closed as WONTFIX, and we have https://bugzilla.gnome.org/show_bug.cgi?id=584236 for the remaining one

*** This bug has been marked as a duplicate of bug 584236 ***