Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!jade!mica!spencer From: spencer@mica.UUCP Newsgroups: comp.sys.amiga Subject: Re: problems with the amiga user interface... Message-ID: <2763@jade.BERKELEY.EDU> Date: Wed, 11-Mar-87 17:40:28 EST Article-I.D.: jade.2763 Posted: Wed Mar 11 17:40:28 1987 Date-Received: Fri, 13-Mar-87 06:13:22 EST References: <50@mit-prep.ARPA> Sender: usenet@jade.BERKELEY.EDU Reply-To: spencer@mica.BERKELEY.EDU (Randy Spencer) Organization: University of California, Berkeley Lines: 114 There are infact several things wrong with the Amiga user interface, below is an article by Mr. Breuel where he lists several that bother him. I had to comment on some of them. In article <50@mit-prep.ARPA> tmb@mit-prep.ARPA (Thomas M. Breuel) writes: > Usually, if I send a window to the back, I don't > want to use it, and it should not become active. The same is true > for the selection of new screens using either the mouse or the keyboard Actuall I don't thing this is true. I spend much of my time sending a window to the back so that I can copy the contents of a window in the front to it. If the front window (or screen) became active I would have no way to activate on the back one to enter text into it. If I want the front one all I need do is click the mouse (or keyboard equivalent). I also don't think that Amiga-N and Amiga-M are useless as I often find I can't move a window to get to the screens depth arrangement gadgets. > (the keyboard equivalents for selecting a new screen are particularly > useless since you always have to use the mouse anyway to activate > a window in the new screen). Therefore: > -- clicking the back (or front) gadget should not activate a window That might be a good compromise, no change of state, but how do you code it? > -- clicking a window and activating it should move it to the front No, no, no... I had AutoPoint, a program written by Jude (formerly of Amiga) and that window to front drove me crazy. I like being able to see what I want to see. If I want the window in front there is a gadget for it. > -- an expand/shrink gadget would be nice Word Perfect has one and it is nice. I can't see how it would cause problems to add that to Intuition. > -- selecting a new screen should activate the front window in that > screen (this is esp. true for the keyboard equivalents) No, I don't think so, see above. > >-- the keyboard equivalents for selecting screens should go through a > circular list rather than just bringing the last screen to the front I have several programs that open windows so big that I can't get to the screen gadgets. If I call workbench to the front I get workbench and if I send it to the back I get that program. I _can't_ get to the other screens at all! This would be a clever suggestion. > >-- there should be keyboard equivalents for cycling through the windows > of a screen I am working with a program by Jim Makraz (author of Intuition part II) and it does this. Pretty nice. > >-- there should be standard keyboard equivalents for 'accept' and > 'cancel' gadgets in requesters Their are, Amiga-B and Amiga-V. > >-- intuition (and the workbench) is unbelievably slow. [many comments] True! (but on a hard disk...) >-- string gadgets in requesters should become activated automatically, > and a standard keyboard equivalent should be provided to cycle through > them String gadgets can become active automatically (under program control.) You can even cycle, but it is a nasty hack. I would like to see something like the Mac tab key to move to next gadget. > >-- the standard font should be small enough to allow for 80 characters in > a workbench window. Alternatively, the standard screen should be a > little bit wider. 80 characters is unfortunately a magic number that > everybody assumes when writing text, and having fewer than 80 characters > on a line means that TYPE'ing a file, running a terminal emulator, &c. > in a workbench window will often result in lines that wrap around for > just one or two characters. You need MoreRows, I have an 80 column CLI and can still see some of the WorkBench screen. > >-- the collection of fonts provided with the system is poor. At least one > of each a no-frills sans-serif and serif font should be provided in > a large range of point sizes (8-36). I hate fonts on the Amiga. There is no way to do them without going to a graphic. I LOVE styles on the Amiga. A word processor can put italic and bold and underline in a file. The file can then be TYPEd or copied to the PRT: and the bold and italic are preserved. That is really nice! I don't think that the Amiga will ever see fonts done correctly. They are always going to be ugly, until we get a standard way to output postscript there is almost no reason to use those Amiga fonts. > >-- the printer drivers often do not support high-resolution graphics printing > even if it is available. The Imagewriter II, for example, can print > at twice the resolution provided by the driver to give near letter > quality printing even in graphics mode. The printer.device is really complex, you can do alot with it. I just think that the user should be able to play with the values before they go to the printer. Like the Mac. When you send something out a requestor (oops, I mean Dialogue Box) comes up and asks you how many copies, what orientation, etc, etc. Now if you could call the printer.device with a specification of "query the user for variables", and then a requestor comes up. Now you wouldn't always want that, so it should just be an option. I just find that the programmer tests it on one printer, and it don't necessarily work on another (though it should). > >-- pop-up menus (perhaps optional, selectable via preferences) would > be nice, in particular for larger screen sizes. Otherwise, why bother > with a two-buttoned mouse anyhow? There is that double click menu that brings up a requester when you double click the menu button. Nobody is using it yet, nobody is using the help key, nobody is using the ability to open a menu with the menu button, and then click on more than one item in the menu with the left mouse button. Programmers I know either don't know about these ablilities, or at least don't think that we do. (we don't do we?) > >-- resource tracking should be added to the operating system so that > processes can be killed. Jobs that don't need would not have to use > it, but it ought be be available. "Is anybody there? Does anybody care? ...Does anybody see...what I see?" John Adams, "1776" -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-