Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sun-barr!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: R3 Selection Mechanism -- The emperor has no clothes!
Message-ID: <1431@bacchus.dec.com>
Date: 19 May 89 16:09:14 GMT
References: <1413@dukeac.UUCP> <8905191417.AA01082@expo.lcs.mit.edu>
Organization: DEC Western Software Lab
Lines: 41

>From: ecsvax!dukeac!bet@mcnc.org  (Bennett Todd)
>In article <3786@mit-amt> geek@media-lab.media.mit.edu (Chris Schmandt) writes:
>> ...
>>             Simplicity should be manifest in the user-interface,
>>   NOT in the underlying architecture supporting it.
>
>Is this sentiment common among X supporters?
>
>... But does
>*anybody* see anything wrong with the above statement, and the design
>philosophy it implies? Or am I just really strange in my head (probable:-).

Chris was perhaps overstating the case; to be completely correct I would
have said "Simplicity should be manifest in the user-interface, and if
complexity is necessary underlying architecture to support it, it's
unfortunate but life isn't always easy."

There are many examples of this in the X architecture.  The vast number of
gotchas that apply to request redirection are necessary in order to allow
consistent window manager operation across all windows.  Someone here at
DEC started rooting around in the intrinsics on the theory that all the
complexity wasn't really necessary but kept coming to the conclusion that
yes, it really *was* necessary to support consistent user interfaces.

The selection mechanism is just another example of this.  One thing
selection provides that hasn't been discussed yet is synchronization
between clients.  If you make a selection in one window, paste (or
otherwise use it) in another, then make another selection, what happens if
the client in the second window is slow and doesn't get around to fetching
the selection until after you've made the other one?  Believe me, this
*can* happen.  All the timestamp business in the selection mechanism is to
allow this to work right.

Yes, complexity is to be avoided when there is a simple alternative, but
sometimes there is no alternative.  Of course sometimes we may just all be
too dense to see what the alternative is, so we should be open to new
suggestions about how to do things, but we have to make sure the simple
alternative really solves all the problems.

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente