Newsgroups: comp.sys.amiga.advocacy
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!mintaka!geech.gnu.ai.mit.edu!rjc
From: rjc@geech.gnu.ai.mit.edu (Ray Cromwell)
Subject: Re:  De-macification of the Amiga (Re: The Amiga's Future)
Message-ID: <1991Jun29.232917.28817@mintaka.lcs.mit.edu>
Sender: news@mintaka.lcs.mit.edu
Organization: The Internet
References: <14300@pasteur.Berkeley.EDU> <1991Jun27.115950.24857@Sugar.NeoSoft.com> <14318@pasteur.Berkeley.EDU>
Date: Sat, 29 Jun 91 23:29:17 GMT
Lines: 83

In article <14318@pasteur.Berkeley.EDU> navas@cory.Berkeley.EDU writes:
>Weeell.  That's one opinion of course.  For the beginner user (which neither of
>us are) there really isn't enough visual clueing as to whether menus exist
>or not.  Witness, if you will, poor Joe user confused the first time he
>fires up dpaint and hits his right mouse button.

   Is our society so illiterate that noone can RTFM anymore? I mean sheesh,
whenever I get a new stereo/vcr I read the manual so I know what its features
and caveats are. Using the right mouse button in paint programs is far
easier to paint with than having to hit a hotkey/gadget/menu item to switch
draw modes. If a user is so stupid that he can't read the manual then
he doesn't deserve a computer. 
" When drawing in FooPaint, the right mouse button no longer functions
normally. The right mouse button now erases pixels. To choose menu items
you must point the mouse to the top of the screen and press the right mouse
button."

>Also, there are some serious intuition-type conflicts that I'm not convinced
>PopUpMenu has solved.
>
>The menu system on the Amiga sucks.  I think the folks at Cmdre know that, its
>a matter of allocation of resources.  Certainly it seemed to be one of jimm's
>laments, although I think he seemed to be dreading attacking the problem. :)
>
>[Intuition's state machine was already broken....]

  I've been looking at the PopUpMenu source and thinking of solutions, but
the problem isn't simple.

Idea #1:
   Get rid of the LockIBase and instead only lock the window's layer.
Render the menu's into the Window's rastport.
 
  Problems: 
   Menu's will be clipped at the Window's border.
   Menu's will overwrite the border pixels on non GZZ windows
   Only one window will have rendering blocked.
   What happens if the task that owns the window decides to
   CloseWindow() and exit? The Window structure/layer might be invalidated
   while I'm rendering into it.

Idea #2:
   Create a new layer for the menus

   Problems:
	Slow rendering
	fragments memory more
	
   Bonuses: Even the active window which the menu is attached too can
	    still render
   Problem: Since the task is no longer blocked from rendering, it is free
	    to close it's window, free the menu strip, and exit
	    while I have the menu's up. Imagine the horrors when I try
	    to send a MENUPICK msg to an invalid msg port.
 
  This still doesn't solve the problem of drawing window outlines
and icons. Do you suggest we call a MoveLayer() and move the whole
window like the NeXT when dragging? Sure it would look smooth on an
A3000, but on an A500 MoveLayer() is horrible. And having layers
for each Icon? YUCK! That would be horrible comparing the way Amiga
icons smoothly drag (vs the Mac dragging an outline)

  Sorry, I must disagree. This is _NOT_ a good thing for the A500/2000.
The Amiga's interface is responsive because of the special cased ways
icons/bobs/menus and outlines are handled. And it's only a minor nitpick.
If you don't like it, put a shell window on every screen, most
Apps have their own screen anyway and the problem disappears.
Unless you suggest C= compile a special 68020/30 version of the OS
with layers/clipping/slective locking for everything. I'd agree.

  Actually, I think menus suck period. It takes to long to select a menu
item. Hotkeys and gadgets are better.

>David Navas                                   navas@cory.berkeley.edu
>	2.0 :: "You can't have your cake and eat it too."
>Also try c186br@holden, c260-ay@ara and c184-ap@torus


--
/ INET:rjc@gnu.ai.mit.edu     *   // The opinions expressed here do not      \
| INET:r_cromwe@upr2.clu.net  | \X/  in any way reflect the views of my self.|
\ UUCP:uunet!tnc!m0023        *                                              /