Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!rutgers!tut.cis.ohio-state.edu!bloom-beacon!THINK.COM!rlk From: rlk@THINK.COM (Robert L. Krawitz) Newsgroups: comp.windows.x Subject: R3 Selection Mechanism Message-ID: <8905261534.AA10608@regin.think.com> Date: 26 May 89 15:34:31 GMT References: <8905261231.AA08339@expo.lcs.mit.edu> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 86 Date: Fri, 26 May 89 08:30:55 EDT From: dsill@relay.nswc.navy.mil >From: Bill Cattey > >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 245 First St. bloom-beacon > |think!rlk Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111