An addition to the clipboard specification

[Toni Ruottu]

  Hi.

On Mon, 2006-06-12 at 13:02 -0500, Shaun McCance wrote:
> I'm late on this thread, but the issue seems to be open still.
> 
> On Thu, 2006-04-20 at 00:54 +0300, Toni Ruottu wrote:
> >   hi
> > 
> > > > I created a patch which sharpens the current specification in the way I
> > > > was requesting.
> > > 
> > > >  - when PRIMARY is set, any selection visualization regarding
> > > >    the old selection (conceptually showing former content of
> > > >    primary) should be cleared
> > >
> > > This may be the traditional way, but it can be also pretty annoying (people 
> > > don't select things just in order to copy&paste them)
> > 
> >   Could you please be more specific. Gtk+ works this way _today_ and I don't
> >   remember anyone complaining about it.
> 
> I have heard lots of people complaining about it. I've seen
> discussions about this on mailing lists and on IRC. It has
> been proposed numerous times to the GTK+ developers that
> selections not be dropped when PRIMARY is lost, but they
> won't do it because they want to adhere to the spec.

There is no such spec. It is only the old behavior from the old UNIX
environment and the suggestion to add this to clipboard specification
was dropped from the final patch I recently posted to this very same
mailing list.

> Now, every time some yahoo comes along and proposes that we
> drop PRIMARY "because it's confusing", my counter-argument
> is that if you don't know about PRIMARY, you'll never see
> it.  It doesn't interfere with the clipboard at all, except
> when using broken programs like xchat.

Exactly.

> But the selection-dropping thing is the hole in my argument.
> Imagine, now, some user that doesn't know about PRIMARY.  He
> uses his clipboard, like he would on any other system, and
> everything works fine.  Except, some applications seem to
> drop his text selection when he leaves them idling for a
> while.  Why are they doing that?  He selected stuff for a
> reason, and the programs are just dropping his work.  How
> aggravating.

Yes. This is why that part was dropped, while discussing the matter.
That is also the reason why it does not exist in the final patch I just
posted.

> Now imagine we don't drop selections when losing PRIMARY.
> Take any one of us that uses PRIMARY.  I can't speak for
> everybody, of course, but I know that my general usage
> of PRIMARY is select-paste-forget.  I don't look at my
> desktop to see what's selected so I know what's been in
> PRIMARY for the last half hour.  So having multiple text
> selections in multiple open windows doesn't confuse my
> PRIMARY usage at all.

Both options are a bit confusing in some cases.

> Dropping selections does more harm than good, and it
> causes an experienced-user feature to interfere with
> non-experienced users.  Specifications are nothing
> more than agreements among people, and we're the
> people.

I hope that one day, one of these two options will be written to the
specification. Implementations can then implement the other option as an
optional feature. However this specification should of course not
describe options, but name the default behavior.

Luckily your response has nothing to do with the final patch I posted,
so it can be applied to the specification before further discussion
about this one specific issue takes place. Actually I'm wondering, if
anyone has rights needed to apply the patch to the specification in CVS.
It seems to take forever. :-/

Thank you for your response.

  Cheers --Toni Ruottu

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060612/b79b0b38/attachment.pgp