Xref: utzoo comp.sys.ibm.pc:15861 comp.windows.misc:528
Path: utzoo!attcan!uunet!husc6!uwvax!oddjob!gargoyle!att!ihnp4!ihuxy!nowlin
From: nowlin@ihuxy.ATT.COM (Jerry Nowlin)
Newsgroups: comp.sys.ibm.pc,comp.windows.misc
Subject: Re: DOS & MS-windows Vs. Unix & X experience + MS-windows Flame
Summary: windows has a keyboard interface that works just fine
Keywords: MS-windows, DOS, Unix, X
Message-ID: <2539@ihuxy.ATT.COM>
Date: 24 May 88 16:19:20 GMT
References: <10799@apple.Apple.Com> <91@dcs.UUCP>
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 54

Before people start knocking something they should make sure they know
enough about it to avoid chewing on their feet at the same time.

In article <91@dcs.UUCP>, wnp@dcs.UUCP (Wolf N. Paul) writes:
> In article <10799@apple.Apple.Com> jrg@Apple.COM (John R. Galloway) writes:
>  >POOR WINDOW MANAGEMENT.  One of the things I lke about the X uwm window
>  >manager (although many feel otherwise) is the use of keyboard and
>  >mouse combinations  e.g. to move a window I need only be in the window and
>  >hit (with my .uwmrc file) ALT + right button to drag the window, ALT + middle
>  >to change its size, etc.  All such items in MS-windows are based on being in
>  >a particular spot on the window (in the border to change its size, in the
>  >title to move it).
>  
> 	 This is EXACTLY the way Apple invented it for the MAC, and presumably
> 	 is one of the issues in the lawsuit :-) ...

There IS a keyboard interface for manipulating the active window in
MS-windows.  An active window can be moved, sized, iconized, restored and
toggled back and forth between full screen size and its previous size all
from the keyboard by use of ALT-function key combinations.  An active
window can also be closed with an ALT-function key combination.

MS-windows provides a facility for "accelerators" to be defined for menu
items that allow items to be selected from the keyboard without even
displaying the menu.  It looks like that's how the window manipulation
commands above are implemented.

>  >POOR DIALOGUE BOXES.  There are a million (ok maybe only 20 or 30) dialogue
>  >boxes that keep poping up to ask "ARE YOU SURE?" and so on.  This would not
>  >be so much of a pain if the box was positioned correctly so that the default
>  >button (the one highlited and clicked by hitting the enter key) was
>  >positioned under the mouse.
>  
> 	 Of course, the MAC's "OK" button does not automatically pop up
> 	 positioned under the mouse pointer either :-) ...

The OK and CANCEL buttons that normally appear in MS-windows dialog boxes
(for instance when you try to close the last window during a windows
session) can also be triggered from the keyboard.  This depends on the
application, but the MS-windows recommended design calls for the return key
to activate the OK button and the escape key to activate the CANCEL button.
Most applications work this way.  If ones you use don't it's not the fault
of MS.  They make the facilities available to applications programmers but
they can't stand behind them with a ruler and crack them on the knuckles if
they don't use everything that's available.

I've used the MAC, the Atari ST, MS-windows and a variety of different AT&T
windowing systems.  There are things about each that I like better then
the others.  Ideally I'd take the best of each and design my own interface.
MS-windows is certainly as good as the others that are available in many
ways and documented MUCH better than some (sorry Atari).

Jerry Nowlin
(...!ihnp4!ihuxy!nowlin)