sas@BFLY-VAX.BBN.COM.UUCP (04/06/87)
I am motor impaired and find it tedious and stressful to use a mouse. I can touch type and don't mind learning a few new keystrokes. I would like to use X windows with my desktop SUN. Right now, I am using a VT-100 hooked up with a wire, but the SUN can fit more lines on its screen. Since I use EMACS, X windows requires using a mouse to switch between telnet windows and the editor. Is there some way to bind the circulate windows command to one of the 34 function keys on my SUN keyboard? I would really like something like the Symbolics interface which lets me press a key and then a window identifier to quickly select that window. Thanks, Seth
rose@THINK.COM.UUCP (04/06/87)
From: Seth Steinberg <sas@bfly-vax.bbn.com> Since I use EMACS, X windows requires using a mouse to switch between telnet windows and the editor. Is there some way to bind the circulate windows command to one of the 34 function keys on my SUN keyboard? I would really like something like the Symbolics interface which lets me press a key and then a window identifier to quickly select that window. If his request seems exotic, something's wrong in X-land. As a matter of principle, you should look most suspiciously at any functionality which is available from one input device only. Why must there be a necessary relation between an operation (e.g., select window) and the means by which it is requested (e.g., mouse)? More specifically: Anything you can do with the mouse, you should be able to do with the keyboard, and vice versa. Reasons: * Switching between home position on a keyboard and holding a mouse costs time and interruptions in concentration. The fewer causes for such interruptions the better. * Different people prefer or need different interfaces, at different times. (See Seth's message, and previous reason.) * If your system is less than completely reliable, sometimes the keyboard or mouse goes off in the trees, and you need to issue commands to get it back. * Greater symmetry makes a system easier to learn and use. Examples: Why not a keyboard menu? If you need just to type a "Y" or "N", it may be faster to pop up a little keyboard icon and mouse the letter. The Symbolics system lets you get a window with Mouse-Left, <Select-L> or via a menu. John Bruner's UW program selects window #N via Option-N. The Apollo mouse position can be modified by cursor keys. (Yes, I know about the converse proposition on that system: bumping the mouse makes your cursor jump unexpectedly. But how come so many of the Apollo DM's excellent features have not been emulated by other systems? E.g., in Genera 7 writing a char to a window clobbers your window positioning. Apollo has a nifty distinction between windows and pads which cures this bug among many others.) I'm usually just a listener, but dealing with unnecessarily asymmetric user interfaces is one of my pet peeves. -- John Rose
jg@jumbo.UUCP (04/06/87)
In article <8704061322.AA23763@ATHENA> sas@BFLY-VAX.BBN.COM (Seth Steinberg) writes: > >Is there some way to bind the circulate windows command to one of the >34 function keys on my SUN keyboard? I would really like something >like the Symbolics interface which lets me press a key and then a >window identifier to quickly select that window. In V10, there is no way to do what you want. V11 has the right facilities to implement commands attached to arbitrary keyboard keys, so it will be possible to implement such a user interface when V11 is available. I recommend strongly that you continue to agitate for this capability in the window managers people are beginning to write for V11; failing that, you will be able to write your own... I will forward your message to the appropriate people I know of, but nothing like some "customer pull" to see that it actually happens. Jim
gancarz@decvax.UUCP (04/07/87)
It wasn't long after uwm was released before I hacked up 'twm'. Twm is a kind of companion for uwm that takes window manager functions as command line input. It's great for aliasing f.inconify to function keys and the like. I suppose you could make a case for adding the functionality to uwm, but twm is small and efficient because it doesn't have all the extra interactive stuff that uwm provides. Where can you get twm? Good question. The intent (not commitment) is to make it part of DEC's next Ultrix-32W distribution. That won't help you much if you're running on another vendor's hardware. I don't know whether it will be put in the public domain or not. I guess that means that I'd have to test it on something other than a VAX. :-) I think Jim (Gettys) has the right idea: Scream loud enough and you'll see that kind of functionality appear in the X11 window managers--which it should. --Mike
wohler@sri-spam.UUCP (04/07/87)
here's my loud scream for allowing uwm functions to be bound to function keys. i bound sunwindow functions like open, close, expose, hide, etc. to function keys via the .ttyswrc file, and found that i used them a LOT! also based on the sunwindow scheme, you could have the function keys send predefined key sequences to the current window. other uses for the function keys are only limited by the imagination. use 'em. --bw
bob@osu-eddie.UUCP (04/08/87)
In article <8704061322.AA23763@ATHENA> sas@BFLY-VAX.BBN.COM (Seth Steinberg) writes: >I am motor impaired and find it tedious and stressful to use a mouse. >I can touch type and don't mind learning a few new keystrokes. Seth, Not to deter you from your original search for a button-driven window manager, but are you able to use a trackball? It is a pointing device that is essentially a mechanical ball mouse lying on its back, and you stroke the ball directly with your fingertips. They are used in several arcade games. A trackball requires far simpler large motor use than a mouse, and you seem to have sufficient small motor (fingertips for typing) ability to handle it. The Sun `Catalyst' catalog (a listing of 3rd-party things that work with Suns, compiled and distributed seasonally by Sun) lists two or three trackballs that claim to be plug-compatible with the optical mouse that Sun sells. This would mean that X could never tell the difference, and you could continue to use and develop the same interfaces as the rest of the upright-rodent-bound world. Disclaimer: As much as I would like to, I have never used a trackball, but it sure seems like a nifty idea to play with for a while. Also, I have no financial interest in either Sun or any peripheral manufacturers. I hope you find a solution that works for you. -- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cb{osgd,att}!osu-eddie!bob (614)292-7348 (office) or -0915 (operators) or -7325 (answering machine)
rusty@weyl.Berkeley.EDU.UUCP (04/09/87)
In article <8704061526.AA14490@ican.think.com> rose@THINK.COM writes: >As a matter of principle, you should look most suspiciously at any >functionality which is available from one input device only. >Why must there be a necessary relation between an operation >(e.g., select window) and the means by which it is requested >(e.g., mouse)? > >More specifically: Anything you can do with the mouse, >you should be able to do with the keyboard, and vice versa. How would you implement, for example, something like MacPaint, where everything can be done from both the keyboard and the mouse? -------------------------------------- rusty c. wright rusty@weyl.berkeley.edu ucbvax!weyl!rusty
haynes@DECWRL.DEC.COM (04/09/87)
"Anything you can do with the mouse, you should be able to do with the keyboard, and vice versa." Why? Should I be able to enter text with my thermometer? Scan in images with my trackball? Tell the time of day with my knob box? Don't be ridiculous. -- Charles
mermell@csse32.DEC.COM (Andy, CSSE DSS, ZK2-1/N71 381-2226) (04/09/87)
> "Anything you can do with the mouse, you should be able to do with the > keyboard, and vice versa." > > Why? Should I be able to enter text with my thermometer? Scan in images > with my trackball? Tell the time of day with my knob box? > > Don't be ridiculous. > > -- Charles > I'll give you 4 reasons. The first and foremost was stated by the original requester, I'll rephrase it: Some people may have handicaps which allow them to use a keyboard but not a mouse. #2: At a conference (ACM SIGCHI) I watched a demonstration of (some other company's) animation software (on some other company's PC). The mouse had disappeared (either stolen or taken for safekeeping, both likely events at large trade shows). With an apology that "some actions would be clumsier to perform" the speaker went on to demonstrate *EVERY* feature in the software package, emulating the mouse from the keyboard. This sure makes a better impression than saying "well, I can do X, but not Y, without a real mouse, so let's just pretend you saw that feature" or "demo canceled, go away, don't see my product, don't want to buy it." #3: (if implemented right) it allows the cursor to be positioned to an exact pixel and then not jiggled when the button is pressed. #4: The workstation is disabled without a functioning mouse. This is frustrating and unnecessary. (for want of a $50 mouse a $40000 workstation is useless). Especially because, with a keyboard, an input device (with arrow keys, no less) still exists.
dce@mips.UUCP (04/09/87)
In article <8704090458.AA11356@decwrl.dec.com> mermell@csse32.DEC.COM (Andy, CSSE DSS, ZK2-1/N71 381-2226) writes: > >> "Anything you can do with the mouse, you should be able to do with the >> keyboard, and vice versa." >> >> Why? Should I be able to enter text with my thermometer? Scan in images >> with my trackball? Tell the time of day with my knob box? >> >> Don't be ridiculous. >> >> -- Charles > >I'll give you 4 reasons. The first and foremost was stated by the original >requester, I'll rephrase it: Some people may have handicaps >which allow them to use a keyboard but not a mouse. and more arguments as to why keyboards should be able to perform other input device functions. Andy, you got the comment backwards. The idea is that the "vice versa" isn't correct in all cases. Your "4 reasons" have little to do with the "Why?" above. I think that we can all see why keyboards must be able to implement pointing device functions. The question is: should various external devices be able to implement all keyboard functions? Charles' point is that some devices are specialized in such a way that complete interchangeability is not possible. You could enter text with a thermometer (and some way to say "now!"), but the only person that would want to do that is someone that is completely paralyzed but has body temperature control. I will say that a mouse or trackball with a reasonable number of buttons can be used in the place of a keyboard given proper software, and at some future date it should be possible to interchange "pointing devices". I can see it now: system troubleshooters with their favorite mice and trackballs hanging from their belts as they go from system, much like slide-rules and calculators have done in the world of math and engineering in the past. -- David Elliott {decvax,ucbvax,ihnp4}!decwrl!mips!dce
chan@hpfcms.UUCP (04/09/87)
Re: trackballs as an "easier" mouse.
I always thought that a trackball would be much nicer than a mouse,
but when I finally got to try one out this week, I discovered a basic
problem with using one with X Windows. It is very difficult to hold
down a button and move the ball at the same time. Since X seems to
be mostly bound to "click and drag", this makes the trackball untenable,
at least for a spaz like me. Other trackballs may have their buttons
positioned to make this easier, but it seems like a fundamental problem
since you basically need to push the buttons and move the ball with
the same part of your anatomy (doesn't that conjure up some amusing
images?).
-- Chan Benson
Hewlett Packard Company
Fort Collins, CO
{ihnp4 | hplabs}!hpfcla!chanhaynes@DECWRL.DEC.COM.UUCP (04/09/87)
I think you missed my point, the original contention was that *any* action that could be performed by only one input device was suspect. The conclusion reached from this premise was that it was necessary to be able to do any mouse action from the keyboard. In your example, if the keyboard had been missing, would the demo have been possible? The original claim was "and vice versa". As far as I can tell, all you have claimed is that any mouse action should be available from the keyboard, to support physically disadvantaged users. Now while I think that this is a laudable goal, I don't believe that *all* of our software should be tailored to support *all* physical limitations. For example, must we restrict the use of color in user interfaces to support colorblind people? How about people with more severe motor difficulties, such that they cannot use a keyboard? The question becomes one of degree. I don't think anyone would contend that we should eliminate all CRT's and all use Braille printers to support blind programmers. The demand that no interface can depend on a mouse is exactly analagous. I have used systems where you could both type with a mouse, and specify position with the keyboard. It was a lot like watching a dancing bear. The amazing thing was not how well it danced, but that it danced at all. Modern input devices are optimized to perform particular functions. The keyboard is primarily a text input device, the best one ever invented. The mouse is a locator, and pointing device, and a very good one, probably the best for workstation applications (see Card and Moran). *Requiring* the pointing device to be able to input text, or the text input device to be able to specify positions is as silly as requiring your knob box to be able to scan images. -- Charles
H_Eidnes%vax.runit.unit.uninett@NTA-VAX.ARPA.UUCP (04/10/87)
Since noone has brought up this particular example, I thought I would mention it: Quite a while ago we had an operating system called Accent (or Spice) running on some of our (now sold) Perq-1s. What I'd like to mention about this system, was that its window manager both had a keyboard interface in addition to the mouse interface. With the keyboard it was possible to (de)iconify, select windows for keyboard input, move windows from top/bottom etc. Resizing and moving of the windows was not supported, but I'd guess the main reason was that the Perq had no cursor keys. If someone would care for a more detailed description, I would be happy to dig it out from the documentation (we still keep it around). I remember that the keyboard bindings for the window-manager functions were "natural" and easy to remember, and I preferred the keyboard interface to the mouse interface (the bindings to mouse keys are harder to remember than ordinary keyboard keys). ------- E-Mail: <h_eidnes%vax.runit.unit.uninett@nta-vax.arpa> H}vard Eidnes (or TeXish: H\aa vard Eidnes) Division of Computer Science, Norwegian Institute of Technology
len@geac.UUCP (Leonard Vanek) (04/10/87)
In article <35@decvax.UUCP> gancarz@decvax.UUCP (Mike Gancarz) writes: > >I think Jim (Gettys) has the right idea: Scream loud enough and you'll see >that kind of functionality appear in the X11 window managers--which it >should. > Okay. Consider this a scream. I would like to get a server implementing a subset of the X protocol running on a big Vax and driving one or more vt220s. Obviously, the window manager talking to this server will not have access to a mouse at all, so there must be an alternative method of giving it ANY COMMAND from the keyboard! Mike, would your twm work on our Vax 8650 -- assuming that I had a vt220 X server, of course? By the way, does anyone have such a server? I have had a go at cutting out the graphic and mouse dependent parts of the X11 protocol, but have not attempted an implementation because I do not have version 11 of X. --------------------------------------------------------------------- Leonard Vanek phone (416) 475-0525 Geac Computers International 350 Steelcase Rd. West Markham Ontario L3R 1B3 Canada UUCP ... {allegra,ihnp4,decvax,pyramid} !utzoo!yetti!geac!len
paul@osu-eddie.UUCP (04/11/87)
It's interesting to note that the people who know the least about the
psychology and philosophy of user interfaces are the quickest to condemn
ideas such as this. For instance, how does the enforced use of a mouse
effect someone who has (for whatever reason) poor hand-eye coordination?
What about someone who has the use of only one hand? And what about
speed and ease of use considerations for normal people? Do YOU like to
have to use the mouse to do trivial cursor motions in MacWrite (as an
example of the _wrong_way_)?
Function keys can be a mixed blessing, but so can extra shift keys, the
use of keyboard and mouse button combinations (just TRY to use the default
setup for uwm with one hand behind your back; then think about someone
who only HAS one hand...). Some of the considerations of a user interface
are religious, but many aren't.
Consistency is a BIG plus also. For instance, clicking on an iconified
xterm makes it open, but the same is not true of a closed GnuEmacs.
Stalman also felt the need to ignore the "standard" mouse icon for in text,
and switched it for the arrow; making Emacs different in yet another way.
(Actually, despite the fact that I use it, I could flame about the
inconsistencies of Emacs for hours...)
A given user interface system (such as X and all X applications) should
by default be very constant and consistent, but it should be very easy
to customize the defaults also. The implementation of this may be much
harder, since the model looks something like:
user actions --> mapping to standard action descriptions --> utilities
and applications
rather than
user actions --> utilities and applications
but the ability to change actions UNIFORMLY is worth the extra work. Using
this model, I could make my F3 key send a (de)iconify event to the current
window by only changing the action mapping. Note also that the concept
of the current window would also be definable in the action mapping.
Just because you don't want to do window ops with your keyboard doesn't does
not give you license to prohibit it entirely. If you don't like it, then
don't use it, but let those that might want to be able to do so. Isn't
this the whole idea behind a customizable window system anyway?
-- Paul Placeway
Department of Computer and Information Science
SNail: The Ohio State University
2036 Neil Ave. Columbus OH USA 43210-1277
ARPA: paul@ohio-state.{arpa,csnet}
UUCP: ...!cb{osgd,att}!osu-eddie!paul
-=-
-- Paul Placeway
Department of Computer and Information Science
SNail: The Ohio State University
2036 Neil Ave. Columbus OH USA 43210-1277
ARPA: paul@ohio-state.{arpa,csnet}
UUCP: ...!cb{osgd,att}!osu-eddie!paulschoet@ernie.Berkeley.EDU.UUCP (04/16/87)
This may not be the answer you wanted, but the Commodore Amiga
has the ability to do with the keyboard ANYTHING you can do with the
mouse. This takes advantage of two extra keys on the keyboard and a
very generalized input handler.
I have also seen (for the Amiga) a "light pen" equipped with a lens
that replaces the mouse. This thing is about the size of a pen and has
such good optics that you can stand across the room and point at the screen
to move the mouse. It is also equipped with two microswitch buttons for
mouse buttons. The company that produced it is working on some handicapped
applications including attaching it to some kind of headpiece. If you want
more information on this, respond to me and I can find out the company name
and how to get in touch with them.
There are people working on an X port to the Amiga, so your favorite
application might still be available.
I don't have experience with the X system, but it occurs to me that
a way to simulate mouse movements with the keyboard would be to write a
keyboard handler that filtered out special control codes and sent messages
to whatever port would have been getting messages from the mouse. The special
keyboard handler would then pass all other keystrokes to the regular keyboard
handler. In other words, you send messages from your new handler to make
the system think the mouse did something.
I don't even know if this is way off base, but from the brief scanning
of the Xlib documentation I've done, it seems like a potential solution.(?)
replies to ...ucbvax!schoet
Steve Schoettler