Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!well!ewhac From: ewhac@well.UUCP Newsgroups: comp.sys.amiga Subject: Re: problems with the amiga user interface... Message-ID: <2755@well.UUCP> Date: Wed, 11-Mar-87 06:40:57 EST Article-I.D.: well.2755 Posted: Wed Mar 11 06:40:57 1987 Date-Received: Thu, 12-Mar-87 19:33:38 EST References: <50@mit-prep.ARPA> Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) Organization: Whole Earth 'Lectronic Link, Sausalito, CA Lines: 195 [ Did you know that you can degauss an HP 9845C monitor with a BASIC command? ] In article <50@mit-prep.ARPA> tmb@mit-prep.ARPA (Thomas M. Breuel) writes: >Below, you will find a sundry collection of things that bother me about >the Amiga user interface, the windowing system, &c., from a user's >point of view. I hope that if people on the net make sufficiently >loud complaints, Commodore may fix some of these problems in later >releases of the operating system.... Assuming, of course, they agree with you :-). >-- window activation and window re-arranging are not coupled in a useful > way: usually, when I activate a window, I want to use it, and it should > come to the front. 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 > (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 Yes. This one bugs me, too. I suspect that there might be a clever software hack to solve this one (don't ask me for specifics, I haven't researched the problem). > -- clicking a window and activating it should move it to the front Wrong. (See below) > -- an expand/shrink gadget would be nice I suppose. > -- selecting a new screen should activate the front window in that > screen (this is esp. true for the keyboard equivalents) Wrong again. PERSONAL_OPINION_ON One of the things I like about Intuition is that it doesn't make any bogus assumptions for you, like bringing a window to the front because you clicked on it. Many times, I want a window active (so I can type in it), while looking at the contents of another window. If Intuition were to bring the activated window to the front for me, it would obscure the other window I want to see. I would then click on the back gadget, which would inactivate it. I would then get P.O'ed at how stupid this machine was. When I put a window somewhere, dammit, it better stay there, unless the application has a damn good reason to do otherwise. Now, if you want the user of your program to be able to have a window come to the front just because he clicked on it, you can write your program to do that. You simply wait for an ACTIVEWINDOW message, then use the WindowToFront() function to bring it to the front. The point is that Intuition was written to let the programmer do whatever he wanted, instead of living with assumptions that s/he or the user may not be happy with. This is the beauty of Intuition. PERSONAL_OPINION_OFF (sort of) >-- the keyboard equivalents for selecting screens should go through a > circular list rather than just bringing the last screen to the front > What if you have 10 screens active? You really want to sift through all of them just to look at the ninth one back (which is probably WorkBench)? That's what the screen priority gadgets are for, anyway. >-- there should be keyboard equivalents for cycling through the windows > of a screen > Why? You've got a mouse; point at the one you want. (Aside: I used to despise mice, now I use it regularly and without irritation when it needs to be used (window sorting, selecting, etc.).) >-- there should be standard keyboard equivalents for 'accept' and > 'cancel' gadgets in requesters > There already are, though I can't remember what they are off-hand. Would anyone at Commodore care to re-publish that one? >-- intuition (and the workbench) is unbelievably slow. A machine with a > blitter should be able to do better than this. What!!?? Have you checked out GEM on the Atari ST's yet? Intuition screams compared to that. What are you used to using? The apparent slowness you observe is because the layers library has to compute damage lists, then redraw all the icons that were previously obscured. Note that this approach only applies to windows that are declared SIMPLE_REFRESH. Another kind of window, SMART_REFRESH, does not suffer from this slowness, but you pay in the form of memory requirements. > What about an alternative > scheme in which each directory contains an info file that holds all the > icons and file names for this directory (comparing dates on this file > and the directory would show when it needs updating). > Oh, please. Don't start this discussion again. >-- string gadgets in requesters should become activated automatically, > and a standard keyboard equivalent should be provided to cycle through > them > Why? Suppose you have more than one string gadget. How is the system supposed to know which one to activate? With the advent of 1.2, we now have a new Intuition function called ActivateGadget() that allows the programmer to do just this for you, if it is appropriate. >-- 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. > Yup, it's irritating. The 'morerows' program will expand the WorkBench screen, allowing 80 columns in a bordered window. If you're stuck with 640 across, you can always open a borderless window and get 80 columns in it. >-- 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 don't like the default fonts, either. But creating a new font is no biggie. Just find yourself a font editor, and away you go. Not to mention the fact that various other (mostly decorative) fonts are available either commercially or in the public domain. >-- it is nice for programs to use colour to enhance the user interface. > Unfortunately, many applications sacrifice quality and usability for > it. Using more bitplanes for graphics costs lots of memory. And, for > some reason, applications that rely heavily on colour for on-screen > presentation seem to generate extremely poor b&w printouts, like DMCS. > (This is not a technical, but a design problem). > You're right; it's a design issue. There are an infinite number of ways to misuse color in a given application. Some programs, however, have done an excellent job of utilizing the standard WorkBench colors to create a neat and coherent-looking user interface. InfoMinder is such a program (I feel). >-- the console driver still does not deal correctly with backspacing > and line cancelling if the line contains control characters > No argument here. This is SO easy to get right that I'm surprised the cruddy input driver hasn't changed, even through two new releases of the OS. >-- starting two jobs under the CLI, like 'run foorun bar' > results in massive disk thrashing. I can imaging why this might > be difficult to fix cleanly, but some hack would definitely be > appreciated. > The hack is to replace AmigaDOS. A lot of people are thinking about this project; no one I know has actually started work in it. >-- 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? > This is not hard to implement. However, it requires the programmer to write the pop-up menu code (you have to open a window, then attach gadgets to it, then wait for IDCMP messages, etc). If you really want something that looks like a pop-up menu, you'll have to write it yourself. Also, Intuition provides a thing called a requestor which can be thought of as a pop-up menu (of sorts). Also, that second button has more uses that just for selecting menus. Applications can get at it and do whatever they want. >-- 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. Once again, a function of the DOS that never got written. Resource tracking may or may not help you recover the system in case of a crash. Since there is no memory protection in the Amiga, any program that happens to be running can, if it wants to, tromp any address in memory. If a running program crashes, it may have mashed some important system thingie. Thus, your entire system has just crashed, though you may not know it yet. Using a resource tracker to unload the offending code will simply leave you with more memory free when the machine finally does go down. Wow, this is long; I'll end it here. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab ihnp4!ptsfa!well!ewhac The Guy in The Cape ..or.. well ---\ "Work FOR? I don't work FOR dual ----> !unicom!ewhac anybody. I'm just having fun." hplabs -/ ("AE-wack")