[comp.sys.amiga] problems with the amiga user interface...

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