Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ncar!husc6!mit-eddie!mit-amt!geek
From: geek@mit-amt (Chris Schmandt)
Newsgroups: comp.windows.x
Subject: Re: R3 Selection Mechanism -- The emperor has no clothes!
Message-ID: <3786@mit-amt>
Date: 17 May 89 17:12:43 GMT
References: <gYQFRmQGG047NGTW0K@athena.mit.edu>
Reply-To: geek@media-lab.media.mit.edu (Chris Schmandt)
Organization: MIT Media Lab, Cambridge MA
Lines: 57

In article <gYQFRmQGG047NGTW0K@athena.mit.edu> wdc@ATHENA.MIT.EDU (Bill Cattey) writes:
>I am writing this note in the hope that the X Consortium will consider
>returning to a simpler mechanism for exchange of data between X clients
>than the selection mechanism.
>...
>Eliminate the entire selection protocol and use the cut buffer protocol
>exclusively.  Make the cut-buffer implementation smarter to handle large
>data transfers.

Rarely do I have anything to say to this list, but...

The selection mechanism in X is provides an extremely powerful
method of inter-client communication, as well as some very useful
(for extensions, anyway) means of negotiated how "typed data" may
be exchanged.  There is every reason to keep it!  I will not go
into much detail, but...

1) Selections may exist for any atom, including new ones you get the
   server to create for you.  I've written clients who do things like
   dial phones through a single "dialer" process by exchanging ownership
   of the "PhoneNumber" selection.  This provides much needed 
   extensibility.

2) The actual series of context switches to obtain the contents of the
   selection provides a nice way of synchronizing activity between
   clients, which (details omitted) is also quite powerful

3) A cut buffer merely exists and is there for the grabbing.  Selections
   allow negotiation about how the selection contents may be converted.
   For example, we're supporting "sound files" and "phone numbers" as
   data types, in addition to such commonality as XA_STRING.  Suddenly
   we get some nice inter-client operability in a multi-media
   environment.

4) If you find selections hard to program, you will find X impossible
   so you may as well quit.  I am used to it taking 3 hours (including
   reading the source and doing a test program) to figure out how to
   do anything new in Xt.  Selections took about 1/2 hour.  Can't
   get much easier.

5) If multiple "selections" appear highlighted, that's bad client
   behavior, not bad mechanism.  In fact the biggest problem remains
   Emacs, which uses cut_buffers instead of selections.

6) Finally: I started using X-windows because I hope it is a window
   system of the '90s.  To build exciting clients and user-interfaces
   your base must be strong and flexible.  Sure, X is a bit of 
   a moving target as things like the ICCCM get resolved, and it will
   be some time before things are consistent as we'd like in this
   regards.  Simplicity should be manifest in the user-interface,
   NOT in the underlying architecture supporting it.

In short (though I know it would not happen!), if the selection mechanism
were dropped as the original poster suggested, it would be time for me
to find a new window system for my work...

chris