tmb@mit-prep.UUCP (03/09/87)
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. Many of these problems could be solved by compatible (application transparent) changes. I also hope that developers will start to think more about these user interface issues. While lots of entertaining and graphically interesting things can be done on the Amiga, a clear and clean interface for an application is still much more important than an interface with lots of (graphical) bells and whistles. Some of the problems with the Amiga user interface seem to me to be the result of trying to avoid being too similar to the MacIntosh. However, much of the Mac's user interface was around before, in the Xerox Star, and in particular the Smalltalk-80 system (e.g. the concept of selection followed by an operation) and can therefore hardly be considered proprietary or copyright by Apple. Others seem to be a result of lack of standardisation. Commodore should, in my opinion, push their developers harder in this area. Some of the deficiencies may be due to time constraints during the development phase. Finally, some of the points above may not even be considered shortcomings by everybody. Your comments are invited. I believe, though, that the graphical Amiga user interface has to improve considerably if the Amiga wants to survive in the marketplace. -------------------- -- 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 -- clicking a window and activating it should move it to the front -- an expand/shrink gadget would be nice -- selecting a new screen should activate the front window in that screen (this is esp. true for the keyboard equivalents) -- the keyboard equivalents for selecting screens should go through a circular list rather than just bringing the last screen to the front -- there should be keyboard equivalents for cycling through the windows of a screen -- there should be standard keyboard equivalents for 'accept' and 'cancel' gadgets in requesters -- intuition (and the workbench) is unbelievably slow. A machine with a blitter should be able to do better than this. The fundamental problem may be the way Intuition has to compute internally which part of a window require refreshing, but this is just my guess. The representation of icons and file names is probably another reason. 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). -- string gadgets in requesters should become activated automatically, and a standard keyboard equivalent should be provided to cycle through them -- the paradigm of selecting a tool and then performing an action with it (e.g. selecting scissors and then cutting) is very impractical. The Smalltalk-80 and MacIntosh approach of making a selection followed by an operation on the selection is much more efficient. -- 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. -- 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). -- 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. -- 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). -- trying to control the aspect ration in a low-density dot-matrix printout is a loosing proposition. The resulting pictures plainly look bad. If one could print at higher resolution, this problem might go away. So far, I would suggest that every application should at least give the option: 1 screen pixel <=> 1 printer dot. People tend to learn rather quickly to ignore distortions on the screen, but asymmetries, discontinuities, and non-uniformities resulting from re-sampling a bitmap make printouts look extremely crummy. -- the console driver still does not deal correctly with backspacing and line cancelling if the line contains control characters -- starting two jobs under the CLI, like 'run foo<cr>run bar<cr>' results in massive disk thrashing. I can imaging why this might be difficult to fix cleanly, but some hack would definitely be appreciated. -- 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? -- 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.
ewhac@well.UUCP (03/11/87)
[ 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 foo<cr>run bar<cr>' > 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")
page@ulowell.UUCP (03/11/87)
tmb@mit-prep.ARPA (Thomas M. Breuel) wrote in article <50@mit-prep.ARPA>: Many observations about the Amiga interface. Without starting any religious wars, I'd like to comment on a few things he said. >window activation and window re-arranging are not coupled in a useful way Amen on this. >should be standard keyboard equivalents for 'accept' and 'cancel' gadgets V1.2 has these. I think they are Amiga-V and Amiga-B ? Maybe not... >intuition (and the workbench) is unbelievably slow. The fundamental >problem may be the way Intuition has to compute internally which part of >a window require refreshing, but this is just my guess. I don't think it is Intuition (or Workbench). Some time ago, Dale Luck said if he had to do it all over again, he would rewrite the Layers library. I think this is what you're seeing. >string gadgets in requesters should become activated automatically They *can* be, in V1.2 ... however, it's an application's descision. >the standard font should be small enough to allow for 80 characters in a >workbench window. the collection of fonts provided with the system is poor. True, although you can replace the standard font, and add as many new ones as you like. There are already hundreds of PD fonts for the Amiga. >the printer drivers often do not support high-resolution graphics printing >even if it is available. Again, PD drivers are available to get you what you need. >Unfortunately, many applications sacrifice quality and usability for [color] Not the Amiga's fault. Bitch at the application programmer. Same with printer aspect ratios. Many of the other criticisms come from the Tripos (AmigaDOS) mentality that Amiga had to accept when their planned DOS wasn't going to be ready (legal hassles). These include poor disk/filesystem performance, poor support for control characters in command lines, resource tracking, etc. I have heard of a number of people say a new DOS for the Amiga is in the works - one that will replace AmigaDOS, will look sort of like UNIX, and will be much better integrated with the Amiga kernel. That's not to say there *is* such a beast -- just that I've heard people talk about one. We can only hope. I'm not saying you should keep quiet about problems the Amiga has. The comment about windows/gadgets is one that I'd never heard before, and I think it's an excellent idea. I, for one, would like to see the layers and intuition libraries changed so that windows can have different colored backgrounds. That way we can all do borderless windows and not have the user confused. It *is* important that when you blast the Amiga software, you aren't really talking about an application programmer's design descisions. ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
ali@rocky.UUCP (03/11/87)
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. Most of the problems you bring up are not problems, just personal taste preferences. For instance, some people, rather than having to click on a window to activate it, would rather just move the mouse anywhere within the window. That's the way Sun does it. I can't deal with that, because most of the time I'm not touching the mouse my cat is. Thank god he can't click it! Another issue is activating a window as soon as you bring a screen up front. There are cases where this might be undesirable --- When I am debugging a program, for instance, I do tons of printfs to the CLI window, and I use A-N/A-M to quickly go back and forth my application screen and the debug output. I don't need the CLI window activated at that instant, in fact, I might want to type things into my application while looking at the CLI window. Anyway, it either case, Intuition is flexible enough as it is to provide users with the kind of interface they want. You need to set up a process in front of intuition (ie, priority 21, say) and have it deal with various events. Then this process could send OTHER events to the appropriate tasks. For instance, such a process could trap mousemove events and as soon as it detects that the mouse is over another window it can send deactivate/active messages to the appropriate windows. None of the tasks themselves would know anything about the change. In fact, in a recent BADGE meeting Jim Mackraz demonstrated such a program. (He was actually using and demonstrating a library he is developing --- This library apparently allows various tasks who want to hook event handlers in front of Intuition to interact gracefully rather than having them fight over who is using F1 for what. If I understood correctly.) Another program we saw was one that allowed the user to switch between windows by just the touch of a key --- it allowed you to activate, in sequence, all the windows in the current screen. I'm sure writing such hooks isn't all that easy, but the point is that it can be done without mucking around with the OS or without C-A having to release yet another version of the operating system. Also, on a related topic, you can change many other things about the CLI --- For instance, I use an interlaced screen, but with a 15 by 8 font, black background, and green characters (kind of like on my H19). The characters look real sharp, and I get 80 of them per line, and 29 lines (I use morerows.) With that choice of colors, I also get no noticable flicker. And all programs still work fine. I love that kind of flexibility! Ali Ozer, ali@score.stanford.edu, decwrl!rocky.stanford.edu!ali
spencer@mica.UUCP (03/12/87)
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 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
page@ulowell.UUCP (03/12/87)
ali@rocky.UUCP (Ali Ozer) wrote in article <175@rocky.STANFORD.EDU>: >You need to set up a process in front of intuition (ie, priority 21, say) Intuition is at prio 50, you'll have to be at 51 or more. That's where a lot of people sit, I suspect (popcli, grabbit, funkeys, encore etc), so pick some random value above that. Make sure you pass along what you don't need. >in a recent BADGE meeting Jim Mackraz ... was actually using a library >that allows various tasks who want to hook event handlers in front of >Intuition to interact gracefully rather than having them fight over who >is using F1 for what. Amen. Let's hope he makes this thing PD, so we can avoid the Mess-DOS "Terminate and Stay Ready" syndrome. (no, load me first! No, load me first! ...) Supposedly, C-A was going to publish a spec for developers saying: "here is the protocol that you should use when developing hot key programs so you don't step all over each other." Like everything else, time and manpower were not on their side. Maybe this is what Jim is coming out with. >Another program we saw was one that allowed the user to switch between >windows by just the touch of a key --- it allowed you to activate, in >sequence, all the windows in the current screen. Charlie Heath (of Microsmiths) has a package called FunKeys that does this. It comes with his FastFonts program (along with a screenblanker). I use them all the time - they work great. Nice fast text generation, alternate workbench fonts, hot keys and tiny screenblanker. Worth the price (this is an endorsement, I guess). ..Bob -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET
cjp@vax135.UUCP (03/13/87)
In article <2755@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: >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. Don't say "standard" when you mean "default". There is no standard Workbench, thanks to Preferences. Programs that need particular colors should open up their own, um, screen I guess (or is it window?). And now, the question we've all been waiting for, what (aside from anagramicity) is the significance of "Bols Ewhac"? Enquiring (sic) minds want to know! Charles Poirier USENET vax135!cjp
gore@nucsrl.UUCP (Jacob Gore) (03/15/87)
/ nucsrl:comp.sys.amiga / ali@rocky.STANFORD.EDU (Ali Ozer) / > Most of the problems you bring up are not problems, just personal taste > preferences. Yep. Please read on. > For instance, some people, rather than having to click on > a window to activate it, would rather just move the mouse anywhere within > the window. That's the way Sun does it. I can't deal with that, because > most of the time I'm not touching the mouse my cat is. Thank god he can't > click it! Another issue is activating a window as soon as you bring a screen > up front. [...] I was kind of weary of bringing up the Sun's interface in this group, but I'm glad you did it for me. I don't know if this true of all models of the Sun, but on Sun-3 (/160, in my case), SUCH OPTIONS ARE USER-CONFIGURABLE! Run the Defaults Editor, and tell it that you want your windows to be click-activated (or whatever the option on the menu is). I'm not trying to single out the Sun as having the model user interface; this is just an example. I have used other window systems that gave the user options of how the interface is to behave. And it is done in an easy way that any end-user can handle, which I'm not sure can be said of the following fix: > Anyway, it either case, Intuition is flexible enough as it is to provide > users with the kind of interface they want. You need to set up a process > in front of intuition (ie, priority 21, say) and have it deal with various > events. Then this process could send OTHER events to the appropriate > tasks. For instance, such a process could trap mousemove events and as soon > as it detects that the mouse is over another window it can send > deactivate/active messages to the appropriate windows. [...] Jacob Gore Northwestern University, Computer Science Research Lab {ihnp4,chinet}!nucsrl!gore
ali@rocky.STANFORD.EDU (Ali Ozer) (03/16/87)
In article <3500003@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: >Ali Ozer writes: >> For instance, some people, rather than having to click on >> a window to activate it, would rather just move the mouse anywhere within >> the window. That's the way Sun does it. > ... I don't know if this true of all models of the Sun, >but on Sun-3 (/160, in my case), SUCH OPTIONS ARE USER-CONFIGURABLE! Run the >Defaults Editor, & tell it that you want your windows to be click-activated. > ... I have used other window systems that gave the user >options of how the interface is to behave. And it is done in an easy way >that any end-user can handle, which I'm not sure can be said of the >following fix: >> ... Intuition is flexible enough as it is to provide >> users with the kind of interface they want. You need to set up a process >> in front of intuition (ie, priority 21, say) and have it deal with various >> events. ... Sorry, I also didn't mean to sound like "well if you want to change the way you select windows, go ahead and write a program." If what I said above about setting up a process in front of Intuition holds true, then it shouldn't be too hard to write a Preferences-like program that lets you specify the type of interface you want to use. This program would let you choose among the various interface types, and then, upon save, would inform a process that runs in front of Intuition what events to watch out for and what to transform them into. Of course, I might be wrong here... Maybe having such a process in front of Intuition would be far too expensive or maybe writing such a process is not as easy as I think it is. If so, then the capability to alter the user interface defaults as probably should have been a part of Intuition rather than something to tack on in front of Intuition, afterwards, like I am suggesting. I would be interested in hearing about the possibility of such a "general purpose" input event controller from people who have done such programming... Ali Ozer, ali@rocky.stanford.edu ps. BTW, thanks for telling me about the "defaults editor" for the Sun. I don't use a Sun often enough, really, and I wasn't ragging on the Sun. I was just using the "default" Sun interface as an example, mainly because I saw it running on the Amiga (during Jim Mackraz's demo).
mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) (03/16/87)
In article <3500003@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: >I was kind of weary of bringing up the Sun's interface in this group, but I'm >glad you did it for me. I don't know if this true of all models of the Sun, >but on Sun-3 (/160, in my case), SUCH OPTIONS ARE USER-CONFIGURABLE! Run the >Defaults Editor, and tell it that you want your windows to be click-activated >(or whatever the option on the menu is). Yes, Sunstools is user-configureable. But it can't be configured to be as friendly as Intuition. [Note: this is purely subjective, of course! How friendly an interface is will vary from person to person.] There's no way to close windows without going through menus. Moving & resizing require either windows or bucky bits. And the list goes on. X is even more flexible (you can put any action you want on any mouse click), but is even less friendly than Suntools. No understanding of function keys. You either have to give up applications getting mouse clicks, or always have to use bucky bits (which is why I use Suntools). The major advantage of X is that the window manager is out in the open, where it can be easily replaced. Like workbench on the Amiga, it's just another user program. Rather than re-writing Intution to add lots of flexibility (and slow down startup), how about a writeup describing what has to happen to _replace_ intution. If you really want something as flexible as X or Suntools, you can then write one (or better yet, talk somebody else into it). If you're like me, you can write something that does exactly what you want, with no flexibility. <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BI: :
bj@well.UUCP (Jim Becker) (03/17/87)
I have been the participant in the "user-interface wars" for a number of different computers. There is NO INTERFACE that will please all of the people, or even half of the people. One of the great things about living here is being able to express your opinion, but you should also assume the position of the other guy before you decide to preach about what should and should not be. Have you read the original Macintosh user interface specification ? I have. It is about thirty pages long. There was 30,000 hours spent in meetings to get that specification intact. But that may not be the best system for interface, only one of them. Yes, there is a point to this message. If you want to change the behaviour of the Amiga Interface for the most part you can. It is very simple, just get into the input stream and convert anything that comes down the pike to what you want. This may not cure all the things that bug you about the interface but it will make you appreciate why the current system works as it does. And after you have customized your own environment and interface as you please there will be noone else in the world that can use it !!! Just like Unix environments !! :-)) Opinions expressed are mine, and you are entitled to have your's too!! -Jim Becker Terrapin Software.
lrj@batcomputer.tn.cornell.edu (Lewis R. Jansen) (03/18/87)
In article <2811@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) writes: >In article <3500003@nucsrl.UUCP> gore@nucsrl.UUCP (Jacob Gore) writes: >>but on Sun-3 (/160, in my case), SUCH OPTIONS ARE USER-CONFIGURABLE! Run the > >Yes, Sunstools is user-configureable. But it can't be configured to be >as friendly as Intuition. [Note: this is purely subjective, of course! >How friendly an interface is will vary from person to person.] There's >no way to close windows without going through menus. Moving & resizing >require either windows or bucky bits. And the list goes on. > > <mike Try again. The L7 key toggles whether a window is closed or not. Hit L7 on an open window, and *POOF* it closes. Also, the L5 key places the 'top' window on the bottom of the stack. VERY nice for 'moving' from one window to another to another without reaching for the mouse; just have the windows slightly overlapping, and the mouse arrow sitting in that overlap area. I have no idea what "bucky bits" are -- however, a shelltool (the window) can do some neato stuff with a variety of escape codes. Send the right codes to a window, and you can move it, resize it, close/open it, change the icon it uses, change the label on the top (great for scrolling a message across), etc. If you are interested, look at the shelltool(1) man page. In any case, it looks like you're given the source to Suntools. I hate to say it, but if it does bother you that much, you at least have the ability to CHANGE thet part you dislike. I haven't tried to actually make a new copy of suntools, however. >[ ... ] >Rather than re-writing Intution to add lots of flexibility (and slow >down startup), how about a writeup describing what has to happen to >_replace_ intution. If you really want something as flexible as X or >Suntools, you can then write one (or better yet, talk somebody else >into it). If you're like me, you can write something that does exactly >what you want, with no flexibility. So imlement NeWS on the Amiga, and then put X on top of it. Best of both worlds. :^) I haven't seen X in action yet, but i have seen NeWS on a Sun 3/160 -- neat stuff. (no X vs. NeWS wars here!) With whatever interface you create, there will be some people who prefer it to anything else, and others that detest it. I abhor the line-mode IBM CMS interface -- but there ARE people that swear by it. (poor, misinformed souls. :^) -- -- Lewis R. Jansen, LASSP Systems Grunt lrj@lasspvax.tn.cornell.edu ...!cornell!lasspvax!lrj The above opinions are for sale or rent. Inquire within.
hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (03/19/87)
Re: Suntools, interfaces, code size Intuition does have a tremendous advantage over Suntools and other UNIX-based windowing systems in that it is an *interrupt-driven process* that runs on top of everything else in the system. Plus, accessing Intuition involves calling a reentrant library which multiple processes can share; all of the window/menu/screen management routines are compact and sharable, unlike Suntools which requires that every Suntools application link in a HUGE library of window management routines. Because Intuition is an interrupt-driven process running at high priority it is always very responsive no matter what the load is on the machine at the time. Contrast this to any UNIX windowing system, which, by the nature of the UNIX interface, tend to bog down and even go DEAD for many seconds when something processor-intensive is going on. (I remember when I was running a simple fractal generator on a Sun 3, Suntools slowed down by a factor of about 100. Just sending a window to the back was an excruciating task, and watching the window sloooowwwwly erase itself, redraw, and have the other windows slooooowly become aware that they need to refresh, was quite amusing and took all of about thirty seconds or so. This was on a MONOchrome Sun, with only the fractal generator running (heavily processor intensive) and other tasks just sitting around waiting for input.) The interrupt-priority scheme on the Amiga is particularly well designed; the things you expect to happen fast, happen fast, all the time, no matter what, and the things you might expect to depend on system and blitter load depend on system and blitter load. Thus Intuition manages to present a very consistent and "intuitive" user interface while remaining very small and requiring almost no overhead on the part of user programs. THAT's a good design, and I think we should all credit RJ, Carl Sassenrath, Dale Luck, and the many other software people at C-A for such a well-thought-out and high performance/overhead user interface. -Mitsu
hadeishi@husc7.HARVARD.EDU (Mitsuharu Hadeishi) (03/19/87)
Re: Suntools, interfaces, code size Intuition does have a tremendous advantage over Suntools and other UNIX-based windowing systems in that it is an *interrupt-driven process* that runs on top of everything else in the system. Plus, accessing Intuition involves calling a reentrant library which multiple processes can share; all of the window/menu/screen management routines are compact and sharable, unlike Suntools which requires that every Suntools application link in a HUGE library of window management routines. Because Intuition is an interrupt-driven process running at high priority it is always very responsive no matter what the load is on the machine at the time. Contrast this to any UNIX windowing system, which, by the nature of the UNIX interface, tend to bog down and even go DEAD for many seconds when something processor-intensive is going on. (I remember when I was running a simple fractal generator on a Sun 3, Suntools slowed down by a factor of about 100. Just sending a window to the back was an excruciating task, and watching the window sloooowwwwly erase itself, redraw, and have the other windows slooooowly become aware that they need to refresh, was quite amusing and took all of about thirty seconds or so. This was on a MONOchrome Sun, with only the fractal generator running (heavily processor intensive) and other tasks just sitting around waiting for input.) The interrupt-priority scheme on the Amiga is particularly well designed; the things you expect to happen fast, happen fast, all the time, no matter what, and the things you might expect to depend on system and blitter load depend on system and blitter load. Thus Intuition manages to present a very consistent and "intuitive" user interface while remaining very small and requiring almost no overhead on the part of user programs. THAT's a good design, and I think we should all credit RJ, Carl Sassenrath, Dale Luck, and the many other software people at C-A for such a well-thought-out and highly responsive user interface. -Mitsu
wagner@utgpu.UUCP (03/19/87)
It seems that, in order to understand this conversation, I need to find out what a 'bucky bit' is. Help, someone? Mail, please, no postings. I will summarize. Michael
mwm@eris.UUCP (03/20/87)
In article <444@batcomputer.tn.cornell.edu> lrj@batcomputer.UUCP (Lewis R. Jansen) writes: >In article <2811@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike (No one lives forever.) Meyer) writes: >>There's no way to close windows without going through menus. > > Try again. The L7 key toggles whether a window is closed or > not. Hit L7 on an open window, and *POOF* it closes. Also, > the L5 key places the 'top' window on the bottom of the stack. > VERY nice for 'moving' from one window to another to another > without reaching for the mouse; just have the windows slightly > overlapping, and the mouse arrow sitting in that overlap area. I know all about the L5 and L7 keys, and use them a _lot_. L7 doesn't CLOSE the window, it ICONIFIES it. I wanted to use Intuition-ish terminology, so chose the thing closest to "quit" under intuition. This lead to much confusion, for which I apologize. > I have no idea what "bucky bits" are -- Bucky Bits started life as bits over & above the shift and control keys: meta, hyper, super, etc (yes, there are keyboards with these creatures on them). When refering to rodents, I use that term to mean ANY keys on the keyboard that must be held down when the mouse button is clicked. It should be noted that LISPMs are going to bucky bits instead of chord'ed mouse buttons or multi-clicks ("Gee, you mean quadruple-left-mouse isn't bound anymore?" "Right, it's been replaced by hyper-meta-cokebottle-left.") > In any case, it looks like you're given the source to > Suntools. I hate to say it, but if it does bother you that > much, you at least have the ability to CHANGE thet part you > dislike. I haven't tried to actually make a new copy of > suntools, however. Gag! I fully intend to write a window manager one of these days. If I could figure out how to replace intuition, I'd do it for the Amiga. Failing that, I'm either going to do it for X V11 (which will have the hooks to do what I want), or NeWS (when/if we get it). > So imlement NeWS on the Amiga, and then put X on top of it. > Best of both worlds. :^) Yeah, but the result wouldn't be as close to what I'd like as Intuition (at least now that I have a copy of AutoPoint). > I haven't seen X in action yet, but i have seen NeWS on a > Sun 3/160 -- neat stuff. (no X vs. NeWS wars here!) X should be seen on uVAXen, not Suns. The Sun version has some serious performance problems. NeWS on a Sun 2 is supposed to be snappier than Sunstools on a Sun 3. I can't wait to see that. Finally, Mitsu mentioned that Unix window managers tend to be dogs, based on his experience with Suntools. He's right, Suntools is a dog (anything which can't open 6 windows on a 4Meg machine without swapping has _real_ problems). The major competition (NeWS and X) isn't nearly as bad. Both of them work by having a server that you send messages to so it will do things for you. NeWS even has light-weight processes (read "tasks") in the server. Mouse events are interrupts, and spawn new tasks in NeWS. Performance should be much better. If nothing else, emulate the intuition/input device running at priority on AmigaDOS by niceing your application. Of course, all this stuff has to be done in spite of Unix. I leave the thought of how something like this will work on the Amiga up to you.... [X won't work: 300K for the server + 100K for each terminal window. But they're nice terminal windows, with scroll bars to go over the history, and etc......] <mike -- But I'll survive, no you won't catch me, Mike Meyer I'll resist the urge that is tempting me, ucbvax!mwm I'll avert my eyes, keep you off my knee, mwm@berkeley.edu But it feels so good when you talk to me. mwm@ucbjade.BITNET