Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!rws From: rws@EXPO.LCS.MIT.EDU Newsgroups: comp.windows.x Subject: Re: R3 Selection Mechanism Message-ID: <8905171601.AA22735@expire.lcs.mit.edu> Date: 17 May 89 16:01:33 GMT References: Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 159 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. It is unfortunate that you did not compose this during the official public review of the ICCCM, when the review committee would have been compelled to respond to it as a body. I believe that the Consortium's present direction of adding complexity to solve problems The selection mechanism has been in the X protocol all along. The fact that the sample clients have not until recently used it has been considered a bug, not a feature. The most common use of selections, to cut and paste between windows is quite expensive. You provide no quantitative (or even qualitative) measurement of this, for even one environment, let alone a reasonable range of environments. This problem will go away when all X users run on machines where context switches are not expensive, but such will not be the case for quite some time. Haven't you realized yet that X is a conspiracy of memory, disk and processor manufacturers? :-) I have made extensive use of the Andrew multi-media editor, but all the selections I paste between Andrew applications are converted to a 7 bit ASCII data stream format. I fail to see the relevance of this statement. Are you extrapolating from one small set of applications to the set of all applications? Or are you suggesting there is a universal data format sufficient for all applications? The programs I have used or written which need efficient data exchange generally adopt private protocols. Do you mean private "protocol", or private "data format"? If you are trying to argue that all exchange of "complex" formats inherently requires private exchange protocols, but are still tightly couple to user interface actions, then perhaps you can provide more defense of that statement. If not, then I don't understand what you intend with this statement. Moreover, the implication seems to be that "efficiency" involves communication with the originating client; this seems to contradict your assertion that involving the originating client causes unacceptable performance problems. Maybe it's my brain, but I've got three products in the world that say your product is too complicated for me to deal with. Well, I don't know if your protocols were reviewed by as varied an audience as the ICCCM, so you have the advantage of us. :-) The user interface is now non-intuitive. The is a garbage argument. The particular user interface chosen for sample clients in R3 has next to nothing to do with the selection mechanism. If you disagree with the user interface, change it, or propose changes to it. What's worse, is that most applications don't yet use selections, so the user is now forced to deal with two selections that often can't be seen where once he only had to deal with one invisible thing. This is a silly argument. You are essentially arguing "The standard is bad simply because not everyone is using it yet". A few hours using R3 xterms has proven to me that implementing signaling to clients as the selection shifts between them is a LOSE! I find it very useful. This seems to be a personal preference sort of thing, one that should be controllable using translations. I believe we have received constructive bug reports to this effect. I will be VERY HAPPY if xterm goes back to unhighlighting the selection when my mouse leaves the window. If you think there are action routines missing that prevent you from defining translations to make xterm work this way, then propose them as additions to xterm. [And I don't recall xterm working this way; it used to unhighlight right when you released the button, not when you exited the window. I never found this behavior desirable.] Having support in the intrinsics does no programmer any good until they feel comfortable dealing with the protocol which was already shown to be too complicated in #3 above. It seems to me that the Intrinsics interface hides a fair amount of the complexity. If you think even simpler interfaces can exist for very common cases, perhaps you can elaborate on what they should be. There is a simpler protocol, cut buffers. The cut buffer protocol was documented (partly on request from CMU) on the belief that some existing environments (e.g. Andrew :-) would not be changed. R3 clients like xterm attempt to "support" both paradigms, because we knew that not all applications (viz. emacs :-) would be immediately converted to use selections. In the long run, I don't believe it is wise to attempt to support both simultaneously. There should be only one selection that the user should have to worry about. You seem to be completely ignoring existing GUIs (some predating X or having nothing to do with X), that have multiple selections. X didn't invent the selection paradigm (nor did it particularly invent some of the basic mechanics), it took it from other systems. Programmers who are less sophisticated should not be forced to penalize their users at the basic cut and paste level. "Less sophisticated" programmers should be using a toolkit. If the toolkit doesn't provide simple enough interfaces, the toolkit should be improved. An application that just draws a few simple graphics should remain simple, but still be a full member of the community when it comes to user interface. If it uses a toolkit, it will. The Andrew system is proof that diverse media types can be cut and pasted between applications by all agreeing to speak 7 bit ascii. I've never been too convinced by Turing arguments. :-) The only point where the cut buffer protocol clearly loses is in the area of large data transfers. It isn't the only way. Suppose I read a file into my editor, and select a paragraph. I then go somewhere else and copy the "looks" (as opposed to the "contents") of the selection. It's not obvious why both sides should have to agree on the format of the contents, and unparse and transfer and parse them, just to throw them away. Or I might select a line and then go to my debugger and say "break there"; the debugger wants more than just the contents of the line. Or I might select "the whole file", and then go to a client that will simply ask for the file name; I certainly don't want to transfer the contents. Client B calling XFetchBytes (for example) would wake up client A which would pour in the data in chunks. You don't provide enough detail for me to really understand your proposal, but this sounds like an X protocol change (not just a conventions change), and as such is extremely unlikely at this stage of the game. This adds one non-intuitive aspect to the user interface: programs 'owning' large 'cuts' must be running to supply the data. Programs 'submitting' small 'cuts' need not. Since no self-respecting programmer should build an application with a bald assumption about data size (curse all those C programs out there with fixed size string buffers :-), this implies to me that all programs must be prepared for this. That seems to put you back at square one. (And yes, all you folks out there who will grep X sources and mail us examples of fixed size buffers, please don't bother. :-)