I don't see any approval of your rewrite on the mailing list, really. 
Anyway, if it is only a rewrite of clipboards.txt, we shouldn't have to change anything, right ? And if it is more than a mere rewrite, I'd like to see a list of relevant changes.

Freedesktop.org doesn't have any formal approval processes. The goal at Freedesktop.org is to reach a consensus. That is why, we collect disagreements and change the specification hoping that in the end everyone likes it. We also try to find some rationale for our choices so we can defend them in an argument. If something goes wrong people may continue the work and create another revision of the specification.

I might not have chosen the best possible url. Here is the latest one. This version also has some line feeds in it. :-)
http://lists.freedesktop.org/archives/xdg/2007-November/008985.html

I'm not sure, if GTK+ was ever verified against the old specification. Atleast not against the latest version I think. However the old specification was more of a description and quite fuzzy, so it might have been hard to verify against that anyway.

Instead of giving a list of changes I could try to give a list of ways in which GTK+ is currently differing from the spec.

 Note that implicit paste is known as "middle click paste" in colloquial
 language. The pointers in below writing doesn't refer to any specific
 technical way of pointing.


 spec: "Implicit paste which is performed on a text field MUST attach the
        pasted text at the current location of the text cursor without moving
        it first.  Selecting the point of attachment on forehand separately
        by moving cursor reduces errors, as the point can be confirmed, even
        altered, before actual pasting takes place. In some applications it
        would also be hard to move the cursor at pasting time. These
        applications include many terminal emulators, for instance."

  bug: in current gtk+ "middle click pasting" happens at the mouse pointer


 spec: "A system implementing the implicit copy/paste feature MUST have a
        PRIMARY pointer which points to the host application with the latest
        implicit copy action and a SECONDARY pointer which points to the host
        with the preceding implicit copy-action. I.e. SECONDARY stores one
        step of copy history. Implicit paste-action pastes PRIMARY, unless
        data pasted from PRIMARY would be equal to the current selection. In
        such case SECONDARY would be pasted instead. Implementing implicit
        copy/paste this way, should make it possible for two implicitly
        copied items to take turns, enabling user to overwrite the items
        multiple times with each other by simply executing implicit paste on
        the same selection continuously."

  bug: gtk+ doesn't implement one step copy history, therefore it is
       impossible to "middle click paste" something on a selection
       as selecting will destroy the original content


 spec: "A selection becoming unselected MUST NOT have any affect on any of
        the three pointers (CLIPBOARD, PRIMARY, SECONDARY)."

  bug: after something gets deselected in gtk+ it is currently impossible
       to "middle click paste" the previously selected content


 spec: "Altering any of the three pointers (CLIPBOARD, PRIMARY, SECONDARY)
        MUST NOT affect any selections. Making a selection in one application
        MUST NOT affect selections in other applications."

  bug: making a selection in one gtk+ application clear selections in other
       gtk+ applications

(In reply to comment #2)
>  spec: "Implicit paste which is performed on a text field MUST attach the
>         pasted text at the current location of the text cursor without moving
>         it first.  Selecting the point of attachment on forehand separately
>         by moving cursor reduces errors, as the point can be confirmed, even
>         altered, before actual pasting takes place. In some applications it
>         would also be hard to move the cursor at pasting time. These
>         applications include many terminal emulators, for instance."
> 
>   bug: in current gtk+ "middle click pasting" happens at the mouse pointer

This is not a bug but a feature in my personal opinion. My way of copying and pasting with a mouse depends on this. And in fact I find it tedious to reposition the cursor in applications that can only paste at the current cursor position. For me this kind of behaviour takes away half of the advantages of middle click pasting.

>  spec: "A selection becoming unselected MUST NOT have any affect on any of
>         the three pointers (CLIPBOARD, PRIMARY, SECONDARY)."
> 
>   bug: after something is deselected in gtk+ it is currently impossible
>        to "middle click paste" the previously selected content

This I find interesting. I always experienced primary selection as something very visual. If deselecting wouldn't change the primary selection it wouldn't be as visual anymore. Yet for practical reasons this might actually be useful.

>  spec: "Altering any of the three pointers (CLIPBOARD, PRIMARY, SECONDARY)
>         MUST NOT affect any selections. Making a selection in one application
>         MUST NOT affect selections in other applications."
> 
>   bug: making a selection in one gtk+ application clear selections in other
>        gtk+ applications

I can't confirm that in this general wording. Can you give a more specific example?

(In reply to comment #3)
> (In reply to comment #2)
> >  spec: "Implicit paste which is performed on a text field MUST attach the
> >         pasted text at the current location of the text cursor without moving
> >         it first.  Selecting the point of attachment on forehand separately
> >         by moving cursor reduces errors, as the point can be confirmed, even
> >         altered, before actual pasting takes place. In some applications it
> >         would also be hard to move the cursor at pasting time. These
> >         applications include many terminal emulators, for instance."
> > 
> >   bug: in current gtk+ "middle click pasting" happens at the mouse pointer
> 
> This is not a bug but a feature in my personal opinion. My way of copying and
> pasting with a mouse depends on this. And in fact I find it tedious to
> reposition the cursor in applications that can only paste at the current cursor
> position. For me this kind of behaviour takes away half of the advantages of
> middle click pasting.

The spec says that it is OK to provide distinct behavior as an option for users with different backgrounds. The specification is supposed to specify the default behavior. But lets discus the subject. Please tell us your typical use cases for "middle click paste".

> >  spec: "A selection becoming unselected MUST NOT have any affect on any of
> >         the three pointers (CLIPBOARD, PRIMARY, SECONDARY)."
> > 
> >   bug: after something is deselected in gtk+ it is currently impossible
> >        to "middle click paste" the previously selected content
> 
> This I find interesting. I always experienced primary selection as something
> very visual. If deselecting wouldn't change the primary selection it wouldn't
> be as visual anymore. Yet for practical reasons this might actually be useful.

Imagine using it this way in a situation where pasting always happens at the text cursor location. ;-)

> >  spec: "Altering any of the three pointers (CLIPBOARD, PRIMARY, SECONDARY)
> >         MUST NOT affect any selections. Making a selection in one application
> >         MUST NOT affect selections in other applications."
> > 
> >   bug: making a selection in one gtk+ application clear selections in other
> >        gtk+ applications
> 
> I can't confirm that in this general wording. Can you give a more specific
> example?

to reproduce:

1) open a text file in Gedit
2) open a Tomboy note
3) select some text in Gedit
4) select some text in Tomboy note
5) notice that the selection in Gedit is no longer selected

> > >   bug: making a selection in one gtk+ application clear selections in other
> > >        gtk+ applications
> > 
> > I can't confirm that in this general wording. Can you give a more specific
> > example?
> 
> to reproduce:
> 
> 1) open a text file in Gedit
> 2) open a Tomboy note
> 3) select some text in Gedit
> 4) select some text in Tomboy note
> 5) notice that the selection in Gedit is no longer selected

After trying this with different applications it turns out this bug depends on the widget used. For instance stock Gtk text widgets (entry, text view) seem to deselect as soon as another application has a selection. But GtkSourceView, WebKitWebView or even Gecko don't do this.

I agree this would indeed be worth fixing.

> > >   bug: in current gtk+ "middle click pasting" happens at the mouse pointer
> > 
> > This is not a bug but a feature in my personal opinion. My way of copying and
> > pasting with a mouse depends on this. And in fact I find it tedious to
> > reposition the cursor in applications that can only paste at the current cursor
> > position. For me this kind of behaviour takes away half of the advantages of
> > middle click pasting.
> 
> The spec says that it is OK to provide distinct behavior as an option for users
> with different backgrounds. The specification is supposed to specify the
> default behavior. But lets discus the subject. Please tell us your typical use
> cases for "middle click paste".

Think of working with source code or markup. You have a string or three-liner that you want to use at several different places. So you select that part and now you are able to scroll through your document and middle click where you want your string to be, this even works over different documents if you have multiple tabs open. The described behaviour essentially depends on the text widget to insert the selection precisely where you click.

(In reply to comment #6)
> > > >   bug: in current gtk+ "middle click pasting" happens at the mouse pointer
> > > 
> > > This is not a bug but a feature in my personal opinion. My way of copying and
> > > pasting with a mouse depends on this. And in fact I find it tedious to
> > > reposition the cursor in applications that can only paste at the current cursor
> > > position. For me this kind of behaviour takes away half of the advantages of
> > > middle click pasting.
> > 
> > The spec says that it is OK to provide distinct behavior as an option for users
> > with different backgrounds. The specification is supposed to specify the
> > default behavior. But lets discus the subject. Please tell us your typical use
> > cases for "middle click paste".
> 
> Think of working with source code or markup. You have a string or three-liner
> that you want to use at several different places. So you select that part and
> now you are able to scroll through your document and middle click where you
> want your string to be, this even works over different documents if you have
> multiple tabs open. The described behaviour essentially depends on the text
> widget to insert the selection precisely where you click.

Moving mouse to some specific place on the screen takes lots of time and requires concentration. Doing that cuts in the middle of your thoughts and it takes a while to resume your thinking once you have done the pasting. Clicking on a mouse button is very cheap in comparison to that. Keyboard can be used together with mouse to allow using both hands in order to increase efficiency, but lets leave keyboard usage out for now and talk about using mouse and mouse only.

If the software is strictly designed to be used by mouse it should in a perfect world have an undo button somewhere that allows you to get back so you can correct your error. Using an undo button requires two steps:
1) move mouse to undo-button
2) click

While doing paste with traditional copy/paste mechanism you'd do the following:
1) move mouse to the place in text where you want the content to be pasted
2) click
3) move mouse to paste-button
4) click

With implicit paste of the current specification the same thing is done by:
1) move mouse to the place in text where you want the content to be pasted
2) click
3) middle click

You are suggesting that it would not be very efficient and, if I understood correctly implying that it would be equally efficient compared to the traditional behavior. Imo the mouse move action that doesn't have to be done is a huge efficiency benefit, when we take into account the concentration that is required while moving the mouse to certain point on screen.

You are further suggesting that it would be more efficient to just:
1) move mouse to the place in text where you want the content to be pasted
2) middle click

I'm doubting your claim because I think one additional click (note that the mouse doesn't have to be moved) is a very cheap price for getting improved accuracy, as lack of accuracy might occasionally require one to use undo-functionality that requires one to move his mouse to a specific place on the screen.

> Freedesktop.org doesn't have any formal approval processes. The goal at
> Freedesktop.org is to reach a consensus. That is why, we collect disagreements
> and change the specification hoping that in the end everyone likes it. We also
> try to find some rationale for our choices so we can defend them in an
> argument. If something goes wrong people may continue the work and create
> another revision of the specification.

I know very well how fd.o works. I have worked eg on the ewmh before there even was an fd.o. 

I'm not going to respond to every detail of your 'spec' claims above, but one
thing has to be said: The terminology is really confused here. If you want to write a spec, this should be fixed first thing. PRIMARY, SECONDARY and CLIPBOARD are 'selections' in X terminology, not 'pointers'. I recommend to talk about the 'selected text' in the application instead of 'selection' to avoid confusion. And it is not clear what a 'host application' might be.

I'd be much more sympathetic if you pointed out weaknesses in the current
clipboard handling in GTK+ instead of just making up a spec and declaring 
GTK+ non-compliance to it a bug...

>  spec: "Implicit paste which is performed on a text field MUST attach the
>        pasted text at the current location of the text cursor without moving
>        it first.  Selecting the point of attachment on forehand separately
>        by moving cursor reduces errors, as the point can be confirmed, even
>        altered, before actual pasting takes place. In some applications it
>        would also be hard to move the cursor at pasting time. These
>        applications include many terminal emulators, for instance."
>
>  bug: in current gtk+ "middle click pasting" happens at the mouse pointer

Just rewriting the spec to say something doesn't make established behaviour
a bug. Middle-click paste is a pretty hidden feature anyway, so any spec revision that spends extensive time specifying it in minutious detail is 
a bit dubious. 

> spec: "A system implementing the implicit copy/paste feature MUST have a
>        PRIMARY pointer which points to the host application with the latest
>        implicit copy action and a SECONDARY pointer which points to the host
>        with the preceding implicit copy-action. I.e. SECONDARY stores one
>        step of copy history. Implicit paste-action pastes PRIMARY, unless
>        data pasted from PRIMARY would be equal to the current selection. In
>        such case SECONDARY would be pasted instead. Implementing implicit
>        copy/paste this way, should make it possible for two implicitly
>        copied items to take turns, enabling user to overwrite the items
>        multiple times with each other by simply executing implicit paste on
>        the same selection continuously."
>
>  bug: gtk+ doesn't implement one step copy history, therefore it is
>       impossible to "middle click paste" something on a selection
>       as selecting will destroy the original content

See above for the general sentiment about specifying easter-egg features 
in excruciating detail. On the specific feature that is discussed here, the one-step history feels oddly invented around the need to find a use for SECONDARY. That doesn't seem a very good strategy to me.

> spec: "A selection becoming unselected MUST NOT have any affect on any of
>        the three pointers (CLIPBOARD, PRIMARY, SECONDARY)."
>
>  bug: after something gets deselected in gtk+ it is currently impossible
>       to "middle click paste" the previously selected content

There may in fact be some argument for deferring the giving up of the PRIMARY
selection. This has been discussed before, I recommend some mailing list and
bugzilla study.

> spec: "Altering any of the three pointers (CLIPBOARD, PRIMARY, SECONDARY)
>        MUST NOT affect any selections. Making a selection in one application
>        MUST NOT affect selections in other applications."
>
>  bug: making a selection in one gtk+ application clear selections in other
>       gtk+ applications

This is just plain wrong. The X selection model has always been that PRIMARY
corresponds to the currently selected text. That is the model that GTK+ implements. 

(In reply to comment #8)
> > Freedesktop.org doesn't have any formal approval processes. The goal at
> > Freedesktop.org is to reach a consensus. That is why, we collect disagreements
> > and change the specification hoping that in the end everyone likes it. We also
> > try to find some rationale for our choices so we can defend them in an
> > argument. If something goes wrong people may continue the work and create
> > another revision of the specification.
> 
> I know very well how fd.o works. I have worked eg on the ewmh before there even
> was an fd.o. 
> 
> I'm not going to respond to every detail of your 'spec' claims above, but one
> thing has to be said: The terminology is really confused here. If you want to
> write a spec, this should be fixed first thing. PRIMARY, SECONDARY and
> CLIPBOARD are 'selections' in X terminology, not 'pointers'. I recommend to
> talk about the 'selected text' in the application instead of 'selection' to
> avoid confusion. And it is not clear what a 'host application' might be.

I'm not referring to any particular technology with those terms. I named them according to names that were commonly used for similar things. That might have been a mistake. I didn't realize people would then try to turn these concepts to those the technical concepts. Please, instead of doing that, go ahead and search/replace the pointer names to foo, bar, baz.

The spec is not even supposed to be X specific. I've discussed the clipboard handling with some HaikuOS developers.
 
> I'd be much more sympathetic if you pointed out weaknesses in the current
> clipboard handling in GTK+ instead of just making up a spec and declaring 
> GTK+ non-compliance to it a bug...

Lots of people have posted different concerns about the different clipboard problems to gtk+ bug tracker. Many such issues remain open and unfixed. Also many of these bugs might conflict each other.

The reason why I wrote the new spec was because people complained to me that free software clipboards feel broken. They did not report to me that gtk+ clipboards were broken. I used to tell them that there is a fine fdo specification and the only problem is that people don't implement it correctly. Then I read through the specification carefully and noticed it was far from complete. Then I simply started working on it.

I further reported the problem here, as I have a personal preference for gtk+.

> >  spec: "Implicit paste which is performed on a text field MUST attach the
> >        pasted text at the current location of the text cursor without moving
> >        it first.  Selecting the point of attachment on forehand separately
> >        by moving cursor reduces errors, as the point can be confirmed, even
> >        altered, before actual pasting takes place. In some applications it
> >        would also be hard to move the cursor at pasting time. These
> >        applications include many terminal emulators, for instance."
> >
> >  bug: in current gtk+ "middle click pasting" happens at the mouse pointer
> 
> Just rewriting the spec to say something doesn't make established behaviour
> a bug. Middle-click paste is a pretty hidden feature anyway, so any spec
> revision that spends extensive time specifying it in minutious detail is 
> a bit dubious. 

In some contexts it happens at the mouse pointer while in other contexts it happens at the text cursor location. My goal was to choose either one, but just one. I have already presented rationale for my choice. Moving the text cursor as a result of pasting now personally seems like a side-effect to me. I also recall doing mistakes because this behavior has originally differed between applications.

> > spec: "A system implementing the implicit copy/paste feature MUST have a
> >        PRIMARY pointer which points to the host application with the latest
> >        implicit copy action and a SECONDARY pointer which points to the host
> >        with the preceding implicit copy-action. I.e. SECONDARY stores one
> >        step of copy history. Implicit paste-action pastes PRIMARY, unless
> >        data pasted from PRIMARY would be equal to the current selection. In
> >        such case SECONDARY would be pasted instead. Implementing implicit
> >        copy/paste this way, should make it possible for two implicitly
> >        copied items to take turns, enabling user to overwrite the items
> >        multiple times with each other by simply executing implicit paste on
> >        the same selection continuously."
> >
> >  bug: gtk+ doesn't implement one step copy history, therefore it is
> >       impossible to "middle click paste" something on a selection
> >       as selecting will destroy the original content
> 
> See above for the general sentiment about specifying easter-egg features 
> in excruciating detail. On the specific feature that is discussed here, the
> one-step history feels oddly invented around the need to find a use for
> SECONDARY. That doesn't seem a very good strategy to me.

So you are talking about baz here.

> > spec: "A selection becoming unselected MUST NOT have any affect on any of
> >        the three pointers (CLIPBOARD, PRIMARY, SECONDARY)."
> >
> >  bug: after something gets deselected in gtk+ it is currently impossible
> >       to "middle click paste" the previously selected content
> 
> There may in fact be some argument for deferring the giving up of the PRIMARY
> selection. This has been discussed before, I recommend some mailing list and
> bugzilla study.

Sounds interesting. What a pity I might already have read some of that. Which mailing list? Gnome bugzilla?

> > spec: "Altering any of the three pointers (CLIPBOARD, PRIMARY, SECONDARY)
> >        MUST NOT affect any selections. Making a selection in one application
> >        MUST NOT affect selections in other applications."
> >
> >  bug: making a selection in one gtk+ application clear selections in other
> >       gtk+ applications
> 
> This is just plain wrong. The X selection model has always been that PRIMARY
> corresponds to the currently selected text. That is the model that GTK+
> implements.

If you do that, then the middle click paste stops being an easter egg feature and it _will_ get in the way of a grand mothers trying to use gnome environment. People use selections for things other than clipboard management. E.g. for marking different parts of text so they can remember it. If you have marked a piece of text you really don't want to get that unmarked because of some easter egg feature visualization.

I was originally on your side for this particular issue. However the issue was discussed in detail at fdo during the years which it took to rewrite the spec. In the end the current way of the spec was not a hard choice to make. http://lists.freedesktop.org/archives/xdg/2006-April/006464.html

> The spec says that it is OK to provide distinct behavior as an option for users
> with different backgrounds. The specification is supposed to specify the
> default behavior.

Note that providing distinct behavior as an option refers, not only to allowing people to configure their system to their likings, but also lighter means like providing distinct functionalities with modifier keys. It might be a good idea to have "cursor moving middle click paste" functionality available behind a modifier key.

We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.