rws@EXPO.LCS.MIT.EDU (05/17/89)
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. :-)wjh+@andrew.cmu.edu (Fred Hansen) (05/20/89)
Bill Cattey wrote:
The user interface is now non-intuitive.
and Bob Scheifler replied:
Th[is] 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.
This raises an obvious question:
If the selection mechanism says nothing about the user interface,
how do I use the selection mechanism to implement ATK cut/paste
protocol?
For those readers who are not familiar with ATK, the following may make
the
problem clearer. In ATK a user can "pick out" material in any window
and cause
it to "appear" elsewhere in that same or another ATK window. In
addition, any of
the last eight items picked out can be retrieved and caused to appear.
In ATK, "picking out" some material means to first select it and then
choose the
Cut or Copy operation. Causing it to "appear" is done by selecting a
destination
and then choosing the Paste or Replace operation. Getting back recently
cut
material is done with the Rotate-Replace operation. The material can be
any
sort of object; currently implemented objects include raster, picture,
animation,
text, spreadsheet cells, .... It is not necessary for the recipient to
know
beforehand what sort of object it is getting; this is appropriate when
the
recipient is just inserting whatever it gets into the destination chosen
by the user.
I have seen some wonderous things done with properties and selections in
X,
so I am issuing this challenge in hopes of learning even more. Again,
the question is
How can I use the selection mechanism to implement ATK cut/paste
protocol?
Fred Hansen
(412) 268-6788 wjh+@andrew.cmu.edu
BITNET: wjh+@andrew
for UUCP try: ...!psuvax1!andrew.cmu.edu!wjh
Omega say, "Enjoy the raspberries."wjh+@andrew.cmu.edu (Fred Hansen) (05/21/89)
> How can I use the selection mechanism to implement ATK cut/paste > protocol? > Your question is not specific enough to provide a real answer. There > are probably lots of ways it could be implemented. But, without knowing > what all of the requirements are, it's probably impossible to know if > any of them are actually adequate. You haven't given any indication of > how non-ATK clients should interact with ATK clients at the UI or > semantic level, you haven't said anything about lifetime of the items. > There may be other things you haven't specified that are crucial (I > haven't thought about it too hard). OK. Let's make it simple and assume that there is no need for interaction between non-ATK clients and ATK clients. (I would like to relax this assumption in practice, but it ought to make the exercise easier.) Lifetime: There are eight cut buffers used in a ring organization. Once a value is placed in a buffer it remains alive until eight subsequent items have been placed in buffers or the window manager is terminated, whichever comes first. - - - - - - - - - - Description There is one set of eight cut buffers shared by all ATK applications and organized in a ring. Text or other items are stored in a cut buffer in an ASCII encoded form. The recipient of the value deciphers the ASCII to determine what variety of object it has received. (ASCII encoding permits arbitrary objects to be stored in a cutbuffer without the need for the sender to have routines to format the object differently for different receivers or for the receiver to have to make an initial handshake with the sender to find out what is available. The particular ASCII encoding is not a part of this exercise.) User interface operations: CUT - the cut ring is rotated and the new top element is replaced with the ASCII representation of the item or text that was selected (in the window where the operation is initiated). The item or text is removed from the original. COPY - the cut ring is rotated and the new top element is replaced with the ASCII representation of the item or text that was selected (in the window where the operation is initiated). The item or text remains unchanged in the original. PASTE - the contents of the top element of the cut ring are inserted at the end of the current selection (in the window where the operation is initiated). ROTATE-PASTE - the ring is rotated in the opposite direction from CUT or COPY and the new top element replaces the selection (in the window where the operation is initiated). - - - - - - - - - - A claim that seems to be implied for the X selection mechanism is that it should be used for communication of values the user wants to move from one X client to another. (Section 10.2 of the C language X interface manual states, "New applications are encouraged to share data by using selections.") An explicit claim on the comp.windows.x bboard was that the X selection mechanism does not affect the user interface. And yet, as far as I can see the X selection mechanism has little to offer in trying to implement the protocol described above. To repeat the statement of the exercise: Show how to utilize the X selection mechanism to implement the above user interface. Fred Hansen (412) 268-6788 wjh+@andrew.cmu.edu BITNET: wjh+@andrew for UUCP try: ...!psuvax1!andrew.cmu.edu!wjh Omega say, "Enjoy the raspberries."
rws@EXPO.LCS.MIT.EDU (05/21/89)
[Stupid mail systems.
The following message was delivered properly, but was automatically rejected
by the recipient's message server for the following reason:
>>>Netnews posting via andrew.cmu.edu is permitted only for users in the
cmu.edu domain. <<<
]
How can I use the selection mechanism to implement ATK cut/paste protocol?
Your question is not specific enough to provide a real answer. There are
probably lots of ways it could be implemented. But, without knowing what
all of the requirements are, it's probably impossible to know if any of them
are actually adequate. You haven't given any indication of how non-ATK
clients should interact with ATK clients at the UI or semantic level, you
haven't said anything about lifetime of the items. There may be other
things you haven't specified that are crucial (I haven't thought about
it too hard).rws@EXPO.LCS.MIT.EDU (05/21/89)
An explicit claim on the comp.windows.x bboard
was that the X selection mechanism does not affect the user interface.
If you think I said this, you think wrong. What I meant is that the
particular user interface provided in the R3 xterm is not compelled by
the definition of the selection mechanism, other user interfaces are
certainly possible. I don't claim that all possible interpretations
of the words "cut and paste" are supported by the selection mechanism, nor
would I want that to be the case.wjh+@ANDREW.CMU.EDU (Fred Hansen) (05/21/89)
> An explicit claim on the comp.windows.x bboard was that the X selection mechanism does not affect the user interface. > If you think I said this, you think wrong. What I meant is that the > particular user interface provided in the R3 xterm is not compelled by > the definition of the selection mechanism, other user interfaces are > certainly possible. I don't claim that all possible interpretations of > the words "cut and paste" are supported by the selection mechanism, nor would I want that to be the case. Ah ha. Good clarification. I was indeed misinterpreting your words. In addition, I think I confused this discussion with claims elsewhere that X specifies mechanism and not policy; i.e., that it does not impose user interface decisions. It seems to me, however, that in recommending the selection mechanism the C language X interface manual does try to impose user interface policy. (I can hardly complain. In similar circumstances I myself would have far less often resisted the temptation to suggest policy :-) Fred Hansen Fred Hansen (412) 268-6788 wjh+@andrew.cmu.edu BITNET: wjh+@andrew for UUCP try: ...!psuvax1!andrew.cmu.edu!wjh Omega say, "Enjoy the raspberries."
rws@EXPO.LCS.MIT.EDU (05/24/89)
Show how to utilize the X selection mechanism to
implement the above user interface.
I kinda doubt anyone's going to take you up on this. I think it's pretty
clear that the Andrew UI is tightly coupled with the cut buffer mechanism
(which is why RotateProperties exists in the protocol, and why cut buffers
are described in the ICCCM). Given the particular constraints, I doubt
there's any elegant way to use the selection mechanism for this UI. But,
as I said, there was no expectation that the selection mechanism would be
suitable for all UIs. On the other hand, I think the selection mechanism
is quite suitable for a range of UIs (both inside and outside X) that are
on the market today, and many product UIs in the X environment will use it.
To maximize "interoperability" between different applications, I do believe
we should encourage use of the mechanism.wjh+@andrew.cmu.edu (Fred Hansen) (05/25/89)
> Excerpts from mail: 24-May-89 Re: R3 Selection Mechanism > rws@expo.lcs.mit.edu (884) > On the other hand, I think the selection mechanism is quite suitable for > a range of UIs (both inside and outside X) that are on the market today, > and many product UIs in the X environment will use it. To maximize > "interoperability" between different applications, I do believe we > should encourage use of the mechanism. At this juncture, I must admit my ignorance. What is the user interface to selections? How is the X selection protocol used in practice? Let's be specific and list some tasks. In the following list, let "xxx" stand for some piece of text, a picture element, or some other selectable quantity. 1. Delete xxx. 2. Make a copy of xxx and insert it somewhere else. 3. Make a copy of xxx and use it to replace something somewhere else. 4. Make a copy of xxx and insert it at several places. 5. Move xxx from where it is to some other place. Problem statement: Describe the user's actions to achieve each of the tasks above, where an action is X select xxx T select target K type a key M pick a menu item C click a mouse button D drag with mouse button down B click the mouse on a screen button or whatever Action letters may be suffixed with lower case letters to indicate which key, button, or item. To indicate actions where some key or button is held down while other actions are done, the suffixes ! and ^ indicate the downstroke and upstroke respectively. Example: Here is the description of the tasks for Andrew. In each case the menu selection (M) could be a key stroke (K). In ATK the S and T selections are done with the left and right mouse buttons. Clicking the left button selects a point between characters. Dragging with the left button down selects everything from where the button goes down to where it goes up. The right button extends the selection from the furthest point of the previously existing selection to the point where the right button goes up. (In ATK there is always exactly one selection in each text; there is no secondary selection or independent typing point.) 1. Delete: S Mcut 2. Copy once: S Mcopy T Mpaste 3. Replace: S Mcopy T Mreplace 4. Several copies: S Mcopy T Mpaste T Mpaste T Mpaste 5. Move: S Mcut T Mpaste Comment: The five tasks are very common editting operations. If we are to "maximize 'interoperability'" can we really ask the user to do them differently in different applications? Fred Hansen
wjh+@ANDREW.CMU.EDU (Fred Hansen) (05/25/89)
> Excerpts from mail: 25-May-89 Re: R3 Selection Mechanism > dsill@relay.nswc.navy.mi (1611) >> What is the user interface to selections? How is the X selection > protocol used in practice? > There is no single interface to selections mandated by the protocol, nor > should there be. Yes, I should have been clearer in my post as to what I thought this bboard discussion ought to be doing. It was my idea that we could collect succinct descriptions of various user interfaces, just so we could compare and contrast them. If this effort does no more than lead to greater understanding, it will have been worth it. If it leads to even a small reduction in the number of schemes a user has to learn, it will be of great value. > A typical counterexample to the single-selection-interface approach is > emacs. It has its own ideas of what constitutes a selection and how > selections are manipulated, and it's nothing like the interface Hansen described. This confuses me because I have believed the ATK cut/paste scheme is close to that of emacs, at least Gosling-emac. The mapping from my description to emacs seems fairly direct: control-@ and the various cursor movement commands to establish the selection (S) and the target (T). Keystrokes (K) instead of menu picks (M) to select the various operations. As I mentioned in my note, the menu ATK picks (M) can also be done with ATK keystrokes (K): ^W cut meta-W copy ^Y paste meta-Y replace So how does emacs differ from ATK? Fred Hansen (412) 268-6788 wjh+@andrew.cmu.edu BITNET: wjh+@andrew for UUCP try: ...!psuvax1!andrew.cmu.edu!wjh Omega say, "Enjoy the raspberries."
dsill@RELAY.NSWC.NAVY.MIL (05/26/89)
>From: Fred Hansen <wjh+@andrew.cmu.edu> >Dave Sill wrote: >> A typical counterexample to the single-selection-interface approach is >> emacs. It has its own ideas of what constitutes a selection and how >> selections are manipulated, and it's nothing like the interface Hansen >> described. > >This confuses me because I have believed the ATK cut/paste scheme is >close to that of emacs, at least Gosling-emac. The mapping from my >description to emacs seems fairly direct: control-@ and the various >cursor movement commands to establish the selection (S) and the target >(T). Keystrokes (K) instead of menu picks (M) to select the various >operations. As I mentioned in my note, the menu ATK picks (M) can also >be done with ATK keystrokes (K): > > ^W cut > meta-W copy > ^Y paste > meta-Y replace > >So how does emacs differ from ATK? Emacs uses the concept of a "region", defined as the area between "point" (where the cursor is) and "mark" (a previously marked location). To remove the region, one uses the kill-region command, typically C-w (^W). To copy the region there's copy-region-as-kill, M-w (Esc W). Pasting is accomplished with the yank command, C-y. Killed sections of text are stored in a "kill ring". The yank-pop command can be used to replace the just-yanked text with the previous section in the kill ring. It's also possible to select a rectangle of text whose corners are at point and mark using kill-rectangle. Kill-line, C-k, kills from point to the end of the current line. There's also kill-paragraph, kill-sentence, kill-sexp, kill-word, backward-kill-paragraph/sentence/ sexp/word, kill-comment, mark-defun, mark-page, and mark-whole-buffer. And, since emacs is extensible, the user can create his own custom marking/killing/yanking functions. So, yes, at a low level it looks as though the mouse-based drag-to- select-then-pick-function-from-menu selection interface can be implemented on top of emacs, but that's not nearly sufficient to replace all of emacs' selection interface. -Dave (dsill@relay.nswc.navy.mil)
wdc@ATHENA.MIT.EDU (Bill Cattey) (05/26/89)
I was hoping that someone else would respond to the issues raised by dsill, but already Fred is following them to a set of conclusions I don't like. > Excerpts from ext.in.xpert: 25-May-89 Re: R3 Selection Mechanism > dsill@relay.nswc.navy.mi (1611) > There is no one-size-fits-all selection interface. Beside the fact that > different interfaces suit different applications, the user is best > suited by providing customizable interfaces. > A typical counterexample to the single-selection-interface approach is > emacs. It has its own ideas of what constitutes a selection and how > selections are manipulated, and it's nothing like the interface Hansen > described. Is it right, then, to say to people new to X but with years > of emacs experience that they must use the new, "better" interface? > Would it be better to allow the user to decide which interface he > prefers and let him switch to the One True Selection Interface if and > when he's ready? Why not allow both to exist concurrently if they don't > get in each other's way? This person may not have been around when the mouse bindings for the selection interfaces for gnuemacs and xterm were being chosen. After gnuemacs adopted the ones from the X10 xterm, X11 xterm changed them. I spent several weeks hypnotizing myself to use the new bindings and to appropriately do without thinking the appropriate sequence depending upon whether I was in gnuemacs or xterm. Customizable interfaces are indeed good. Why, you may wonder have I not established my own mouse and key bindings and set them up if I hate the changing defaults so much? Two reasons: 1. I often help new users. I use the system defaults so that I reflexively do what they are supposed to do, and always know what the default is. If they have customized, I can ask them. If they have not, I must know the defaults because they may not. 2. The default bindings of the various common X applications such as X term, and their various customization mechanisms have changed so much that it is faster for me to learn the new defaults cold (much as I may hate them for their difference from what I am used to) than to learn the customization mechanism. I adopted a similar strategy back when the keyboard commands of the various versions of unix diverged. I taught myself to always say 'page' rather than 'p' or 'p1' or 'more' because that was the common pagination program common to all versions I was using at the time. ---- The most important issue here is being ignored: The ATK developers are willing to change their user interface if they hear suggestions that will make it more uniform with what other people use. I hate replies that say the selection mechanism can't be made to do the exact user interface stated, or that there is no best user interface, or that the only good interface is one that can be changed. I consider them lazy. Even silence would provide a space where a creative person could suggest something. Here is one suggestion which I have made privately to Andrew developers which I pose as a starting point for further discussion: 1. Instead of having 8 cut buffers common to all ATK windows, consider having each ATK application have its own seperate kill ring analagous to the gnuemacs kill ring. (I further suggest that the depth of the kill ring be a configurable parameter.) 2. That the X selection mechanism be used as a way to communicate among ATK and other X applications by providing mouse, menu, and key bindings that set the X selection appropriately when the cut/copy/paste/replace commands are issued to effectively share the topmost element of a particular window's kill ring. 3. Setting the selection: The current ez mouse bindings for highlighting text are the same as xterm's. Leave them that way. However it is inconvenient for ATK as it is written to make the highlit text into an X selection, so only make the highlit text an X selection when a cut/copy/paste/replace operation is performed. 4. Cut/Copy: When the cut or copy command is issued the highlit text is copied into the topmost element of the ATK window's kill ring. The window then asks for ownership of the selection if ever asked for the selection produces the topmost element of the kill ring, making such conversions as the ATK developers are interested in coding into their X support. 5. Paste: Tricky! We must prevent the selection from blowing away the topmost element of the window's kill ring. If there is a selection, not owned by this window, copy IT onto the kill ring, and insert the selection into the text. 6. Replace: First cut: ignore the X selections for simplicity. Remove the text from the buffer, rotate the window's kill ring, and insert the contents of the kill ring in its place. 7. Advanced replace: If there is a selection, not owned by the window, put it into the kill ring, rotate the kill ring, and ask for ownership of the selection. When a selection request comes in, produce an appropriately converted copy of the contents of the topmost element of the kill ring. Ok kids, I've got my asbestos eyeglasses all prepared for your replies. From the 'desk' of _ /| Bill (the) CATTey... \'o.O' ~(___)~ THSHVPPPOOO! U ACH!
janssen@titan.sw.mcc.com (Bill Janssen) (05/26/89)
In article <3786@mit-amt>, geek@mit-amt (Chris Schmandt) writes: >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... This kind of response makes me think that perhaps people need window systems less than namespace servers... The Selection Mechanism is indeed a powerful and useful thing. It also seems to be logically separable from the window system. Bill
janssen@titan.sw.mcc.com (Bill Janssen) (05/26/89)
In article <QYSkKdS00VsP0Poa14@andrew.cmu.edu>, wjh+@andrew (Fred Hansen) writes: > What is the user interface to selections? There is no prescribed user interface. The cut-buffer protocol Fred describes would serve as well as anything else, *if* there was a cut-buffer client daemon that managed the selections on behalf of all users. Bill
dsill@RELAY.NSWC.NAVY.MIL (05/26/89)
>From: Bill Cattey <wdc@athena.mit.edu> > >This person may not have been around when the mouse bindings for the >selection interfaces for gnuemacs and xterm were being chosen. So what? I'm not picking on the the xterm or emacs mouse bindings, I'm saying that defining a single selection interface for all applications and users is folly. >The most important issue here is being ignored: The ATK developers are >willing to change their user interface if they hear suggestions that >will make it more uniform with what other people use. So I should kiss the ground they walk on? Developers are *obligated* to provide the best interface they can. >I hate replies that say the selection mechanism can't be made to do the >exact user interface stated, or that there is no best user interface, or >that the only good interface is one that can be changed. I consider >them lazy. Even silence would provide a space where a creative person >could suggest something. Well, if my posting prevented some creative genius from suggesting a truly revolutionary concept in selection mechanisms, then I'm sorry. But I *do* think I had a valid point to make. Any attempt to impose a simple mouse-drag selection interface on all clients is foolish. Define the programmatic interface any way you want, but allow the client to choose the interactive interface. If you want to provide a toolkit selection interface, that's fine too; so long as it's optional. >Here is one suggestion which I have made privately to Andrew developers >which I pose as a starting point for further discussion: > >[Emacs-like kill-ring on a per-window basis, managed by an exterior >mechanism.] What's that got to do with the user interface to X's selection mechanism? -Dave (dsill@relay.nswc.navy.mil)
rlk@THINK.COM (Robert L. Krawitz) (05/26/89)
Date: Fri, 26 May 89 08:30:55 EDT From: dsill@relay.nswc.navy.mil >From: Bill Cattey <wdc@athena.mit.edu> > >This person may not have been around when the mouse bindings for the >selection interfaces for gnuemacs and xterm were being chosen. So what? I'm not picking on the the xterm or emacs mouse bindings, I'm saying that defining a single selection interface for all applications and users is folly. I can't believe that the X developers refuse to listen to this argument. Actually, I should amend that statement: I can very well believe it, both because it's happening, and because it was my experience at Project Athena that this was true, both for X10 and X11. Despite all the ballyhoo that X does not dictate policy (and yes, the underlying protocol certainly doesn't dictate the sort of policy that users see), the X developers certainly do. (flame " This person most certainly was around when key bindings for emacs and xterm were being chosen. I was disappointed enough with the xterm bindings, on the grounds that it's too easy to click the unshifted mouse accidentally and wreak all sorts of havoc. I argued strongly against changing the emacs mouse bindings simply on the grounds that the xterm mouse bindings were such and such (since when is xterm the only standard, anyway?), but I was overruled. Fortunately I wasn't the one who did the deed, as I was in the process of leaving at the time. Whatever the technical merits for the change were, I think the idea that all applications should use the same mouse buttons for selections is bogus, because different applications have different user interface needs. Fortunately, it's easy to change the bindings in emacs, as they're done in emacs lisp with a very simple interface; fixing the xterm bindings is more of a pain and not very well documented. ") >The most important issue here is being ignored: The ATK developers are >willing to change their user interface if they hear suggestions that >will make it more uniform with what other people use. So I should kiss the ground they walk on? Developers are *obligated* to provide the best interface they can. The important issue isn't whether the toolkit developers are willing to change the interface, although I'm not convinced that wdc's statement is true. The issue is whether the toolkit developers are willing to make it easy for application developers and users to change their interfaces. So maybe it isn't the X protocol or Xlib that's dictating policy; if the developers of the toolkits are going to dictate policy that strongly, they are going to force people either to conform to a standard they don't like and is completely artificial in any event, or write their own toolkit (which more or less means dropping into Xlib, which is what toolkits are supposed to minimize the need for), or bypass the toolkits entirely. Is that really what's best for everyone? >I hate replies that say the selection mechanism can't be made to do the >exact user interface stated, or that there is no best user interface, or >that the only good interface is one that can be changed. I consider >them lazy. Even silence would provide a space where a creative person >could suggest something. Well, if my posting prevented some creative genius from suggesting a truly revolutionary concept in selection mechanisms, then I'm sorry. But I *do* think I had a valid point to make. Any attempt to impose a simple mouse-drag selection interface on all clients is foolish. Define the programmatic interface any way you want, but allow the client to choose the interactive interface. If you want to provide a toolkit selection interface, that's fine too; so long as it's optional. Yes! And as for the accusation that users or application developers are being lazy, let me say this: Users are expected to be lazy, and toolkits are supposed to relieve app developers of a lot of the grunge in writing applications, and if they have to spend all their time fighting the toolkit to do a good interface, they have a lot less time to spend doing useful things. Needless to say, I don't consider writing lots of hair to define mouse clicks terribly useful... ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111