Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Archive » net.micro.mac » Time for SubMenus
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Time for SubMenus [message #150215] Mon, 30 September 1985 23:49 Go to next message
keith is currently offline  keith
Messages: 27
Registered: May 2013
Karma: 0
Junior Member
Article-I.D.: ssc-vax.256
Posted: Mon Sep 30 23:49:23 1985
Date-Received: Wed, 2-Oct-85 07:58:12 EDT
Distribution: net
Organization: Boeing Aerospace Co., Seattle, WA
Lines: 24

This is an open call to Apple INC for a possible enhancement to the Mac via
the new ROMs.

I've been examining the Amiga, which in general has a poorer user interface,
but one of it's features caught my eye.  SubMenus.

The submenu is an optional menu placed at the side of an item on an already
open menu.  From there, the user can select more detailed information concerning
the main item.  For example, the desired fontsize of a selected font.  It's
neat.

Well, that's the best I can do to make it a reality.  Further discussion and
opinions on the net might sway the Apple giant into action. How about it?

                                             keith



"...
They showed you a statue 
And told you to pray.
They built you a temple
And locked you away.
..."
Re: Time for SubMenus [message #150247 is a reply to message #150215] Thu, 03 October 1985 20:19 Go to previous messageGo to next message
usenet is currently offline  usenet
Messages: 556
Registered: May 2013
Karma: 0
Senior Member
Article-I.D.: ucbvax.10531
Posted: Thu Oct  3 20:19:45 1985
Date-Received: Sat, 5-Oct-85 02:18:28 EDT
References: <256@ssc-vax.UUCP>
Reply-To: korn@ucbcory.UUCP (Peter "Arrrgh" Korn)
Distribution: net
Organization: University of California, Berkeley
Lines: 18

Um, unless I'm mistaken, the Mac already supports sub-menus in a way that
the Amiga never will.  You see, you can define you're own menu types.
If you notice the rightmost menu "Keypad" in MacTerminal, you've got an
example of a custom menu-type.  To make a sub-menu, you'ld simply define
you're own menu type.  True, it's not supported by the OS routines in
that the Mac will tell you which item in the sub menu you called, nor will
you be able to make command-key assignments the way you would for normal
menus, but you still can have them.

The major trouble with sub-menus, it seems to me, is exactly how you would
implement them.  I personally dislike the way the Amiga did them.  It
lacks the polish and class of the Mac's envorinment.  I'm not quite sure
just how I'd implement them myself.

But!!!, if you really want Apple to do something such as this, I'd suggest
that you make a program w/sub-menus (custom ones) and then send a copy
to Apple and the net, to get a response.  I'd like to see such myself,
but I'm not sure whether it can be done in a smooth, clear, and polished way.
Re: Time for SubMenus [message #150249 is a reply to message #150215] Thu, 03 October 1985 10:33 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: allison@convexs.UUCP
Article-I.D.: convexs.27000009
Posted: Thu Oct  3 10:33:00 1985
Date-Received: Sat, 5-Oct-85 06:30:18 EDT
References: <256@ssc-vax.UUCP>
Lines: 23
Nf-ID: #R:ssc-vax.UUCP:-25600:convexs:27000009:000:1338
Nf-From: convexs.UUCP!allison    Oct  3 09:33:00 1985


 >  This is an open call to Apple INC for a possible enhancement to the Mac via
 >  the new ROMs.
 >  I've been examining the Amiga, which in general has a poorer user interface,
 >  but one of it's features caught my eye.  SubMenus.
 >  The submenu is an optional menu placed at the side of an item on an already
 >  open menu.  From there, the user can select more detailed information con-
 >  cerning the main item.  For example, the desired fontsize of a selected font.
 >  It's neat.
 >                                               keith

I don't know about this!  First of all, you can always do like Microsoft Word
if you want sub-menus.  However, I think that is one of the main weaknesses
of Word - two selections are required just to change a font!  Back to the 
example at hand, what if the user wanted to change the fontsize without
changing the font?  Are you still going to require him to select the (same)
font?  Or are you going to have another menu, for font sizes, in this case?
Sounds like this idea is a waste of ROM space.  There probably are cases
where the submenu idea is valid, but I doubt if that is the general rule.

Brian Allison              {allegra, ihnp4, uiucdcs, ctvax}!convex!allison
Convex Computer Corp.                          - OR -
Richardson, TX         {allegra, ihnp4, uiucdcs, ctvax}!convex!convexs!allison
Re: Time for SubMenus [message #155854 is a reply to message #150215] Sun, 06 October 1985 22:21 Go to previous messageGo to next message
warack is currently offline  warack
Messages: 19
Registered: August 1985
Karma: 0
Junior Member
Article-I.D.: aero.492
Posted: Sun Oct  6 22:21:48 1985
Date-Received: Sat, 12-Oct-85 17:34:53 EDT
References: <256@ssc-vax.UUCP> <27000009@convexs>
Reply-To: warack@aero.UUCP (Chris Warack)
Followup-To: net.micro.mac
Organization: The Discordian Society
Lines: 47
Summary: Elegant sub-menus

overlap
the first menu.  The first item of the sub-menu would be next to the
main menu item.  If the user moves the mouse directly on the sub-menu
(still dragging), he can then choose any item on the sub-menu just as if
it was a main menu.  If he moves the mouse back to the main menu and/or
away from the sub-menu item on the main menu, the sub-menu disappears.
In summary, the sub-menu works like a main menu, but instead of being
pulled-down from the menu bar, it is pulled down by high-liting its item
in another menu.

The advantages of this:  It can be used to keep menus less cluttered by
allowing more levels of grouping.  It is much faster than using dialog
boxes.  It could be easily implemented -- just allow menu items to
include menus (thus menu-select and other toolbox calls would return the
correct codes and they could be stored as menu resources and used in
menu bars as well -- sub-menus would have to have unique menuID's of
course). 

Disadvantage:  Although I said easy to implement above; I meant this on
an application level.  It would require some low level witchery by Apple
to implement.

Note that this kind of implementation would allow (theoretically) a
number of nested sub-menus.

What do people think?  BTW, how does the Amiga do it?

Chris
-- 
 _______
|/-----\|  Chris Warack			(213) 648-6616
||hello||
||     ||  warack@aerospace.ARPA
|-------|  warack@aero.UUCP
|@  ___ |  {seismo!hao | tektronix}!hplabs \
|_______|                          !sdcsvax - !sdcrdcf!trwrb!trwrba!aero!warack
  || ||  \   Aerospace Corporation, PO Box 92957, LA, 90009, Station M1-117
 ^^^ ^^^  `---------(|=
Re: Time for SubMenus [message #155865 is a reply to message #150215] Sun, 13 October 1985 19:31 Go to previous messageGo to next message
lamy is currently offline  lamy
Messages: 8
Registered: September 1985
Karma: 0
Junior Member
Article-I.D.: utai.804
Posted: Sun Oct 13 19:31:59 1985
Date-Received: Sun, 13-Oct-85 20:20:03 EDT
References: <256@ssc-vax.UUCP> <27000009@convexs> <492@aero.ARPA>
Reply-To: lamy@utai.UUCP (Jean-Francois Lamy)
Organization: CSRI, University of Toronto
Lines: 20

In article <492@aero.ARPA> warack@aero.UUCP (Chris Warack) writes:
 > (...)  The first item of the sub-menu would be next to the
 > main menu item.  If the user moves the mouse directly on the sub-menu
 > (still dragging), he can then choose any item on the sub-menu just as if
 > it was a main menu. (...)
 > 
 > What do people think?  BTW, how does the Amiga do it?
 >  (...)


As far as I can tell, this is exactly the Dandelion approach (except of course
that Xerox uses pop-up menus or menus fixed in a pane).  Would Xerox sue?
( :-(  , Apple!) (How do you make a face with a tongue sticking out?).

Such sub-menus are very easy to use.  It does not mess with the very important
capability of being able to look at all the choices available through menus.

Jean-Francois Lamy
U. of Toronto: lamy@utai.toronto.csnet, {decvax,allegra,utzoo}!utcsri!utai!lamy
U. of Montreal: lamy@iro.udem.cdn (from csnet: lamy%iro.udem.cdn@ubc.csnet) .
Re: Time for SubMenus [message #155866 is a reply to message #150215] Fri, 11 October 1985 14:16 Go to previous messageGo to next message
granvold is currently offline  granvold
Messages: 33
Registered: May 2013
Karma: 0
Member
Article-I.D.: tymix.554
Posted: Fri Oct 11 14:16:47 1985
Date-Received: Mon, 14-Oct-85 03:25:21 EDT
References: <256@ssc-vax.UUCP> <27000009@convexs> <492@aero.ARPA>
Reply-To: granvold@tymix.UUCP (Tom Granvold)
Followup-To: net.micro.mac
Distribution: net.micro.mac
Organization: Tymnet Inc., Cupertino CA
Lines: 7
Keywords: submenus
Summary: Yes the Amiga does it.

-
	Yes the Amiga has submenus that come out from the side of the main
menu, at least my Amiga has them :-)  As far as I can tell on the Amiga
only one level of submenu is allowed.

Tom Granvold
ucbvax!allegra!olivab!tymix!granvold
Re: Time for SubMenus [message #155947 is a reply to message #150215] Wed, 16 October 1985 14:01 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: adams1@gumby.UUCP
Article-I.D.: gumby.3
Posted: Wed Oct 16 14:01:04 1985
Date-Received: Fri, 18-Oct-85 21:18:41 EDT
References: <256@ssc-vax.UUCP> <27000009@convexs> <492@aero.ARPA> <804@utai.UUCP>
Organization: U of Wisconsin CS Dept
Lines: 17

 >  Such sub-menus are very easy to use.  It does not mess with the very important
 >  capability of being able to look at all the choices available through menus.

Well, I am pretty good with my mouse and I even had problems with the Amiga
sub-menus.  When I see others having trouble choosing things off a mac menu,
or missing a push button, I wonder how hard of a time THEY would have using
sub-menus.  For those of you who haven't tried one, they are a pain.  You go
up and grab your main menu, then move down to the item you want, then you
have to *carefully* navigate a ninety degree turn and go off to the right,
then pick your sub-menu item.  If you accidentally move too far up or down
(usually RIGHT BEFORE you get to the sub-menu, then you will have chosen the
WRONG main menu item, and will be on IT'S sub-menu.
  I invite every one to try an amiga, and then decide if this is what you
  really want.
  
  Dennis Adams
  adams1@gumby.wisc.edu
Re: Time for SubMenus [message #156052 is a reply to message #150215] Sat, 19 October 1985 21:41 Go to previous messageGo to next message
tim is currently offline  tim
Messages: 230
Registered: February 2013
Karma: 0
Senior Member
Article-I.D.: k.610
Posted: Sat Oct 19 21:41:28 1985
Date-Received: Thu, 24-Oct-85 00:25:40 EDT
References: <3@gumby.UUCP>
Organization: Carnegie-Mellon University, Networking
Lines: 31

Dennis Adams made some good points concerning the difficulting of using the
proposed submenus.  This can't be solved by having them pop up overwriting
the current menu, because that destroys browsing and access to lower menu
items.

One solution is directly moving the mouse location to the start of the
sub-menu, which you can do by twiddling marginally documented low-memory
globals.  But if you were really trying to run down the list of menus, this
wouldn't be very nice, since you'd be back to the right-angle precision turn
that Dennis rightly complained about.

Perhaps the only easy-to-use solution would involve a fusion approach.  When
the mouse passes over a menu item which opens a submenu, the submenu appears
to the right.  The submenu can be directly moved to using mouse movement, or
the main menu item may be selected.  If the latter, the mouse button is
released while still selecting the main menu item.  This causes the menu
definition to be called with mChooseMsg.  The menu definition can look at
the item, see if it opens a submenu, and if so, move the mouse location onto
the submenu and allow selection from the submenu.

I hope everyone realizes that submenus would require that extending the Menu
Manager.  The popping up of submenus during mouse dragging cannot be
controlled directly by the menu definition procedure; the only way to do
this in the current system would be to install a vertical retrace task on
mDrawMsg that checks to see if conditions are such that a submenu should be
brought up or removed, removing it on mChooseMsg.  That would be incredibly
kludgy, though not impossible.
-=-
Tim Maroney, CMU Center for Art and Technology
Tim.Maroney@k.cs.cmu.edu	uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim
CompuServe:	74176,1360	My name is Jones.  I'm one of the Jones boys.
Re: Time for SubMenus [message #224230 is a reply to message #150215] Mon, 28 October 1985 14:32 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: lewak@sdcsvax.UUCP (George Lewak)
Article-I.D.: sdcsvax.1166
Posted: Mon Oct 28 14:32:53 1985
Date-Received: Thu, 31-Oct-85 23:26:45 EST
References: <3@gumby.UUCP> <610@k.cs.cmu.edu.ARPA>
Reply-To: lewak@sdcsvax.UUCP (George lewak)
Organization: EECS Dept. U.C. San Diego
Lines: 42
Summary: 

In article <610@k.cs.cmu.edu.ARPA> tim@k.cs.cmu.edu.ARPA (Tim Maroney) writes:
 > ...
 > One solution is directly moving the mouse location to the start of the
 > sub-menu, which you can do by twiddling marginally documented low-memory
 > globals.  But if you were really trying to run down the list of menus, this
 > wouldn't be very nice, since you'd be back to the right-angle precision turn
 > that Dennis rightly complained about.
 > 
 > Perhaps the only easy-to-use solution would involve a fusion approach.  When
 > the mouse passes over a menu item which opens a submenu, the submenu appears
 > to the right.  The submenu can be directly moved to using mouse movement, or
 > the main menu item may be selected.  If the latter, the mouse button is
 > released while still selecting the main menu item.  This causes the menu
 > definition to be called with mChooseMsg.  The menu definition can look at
 > the item, see if it opens a submenu, and if so, move the mouse location onto
 > the submenu and allow selection from the submenu.
 > 
 > I hope everyone realizes that submenus would require that extending the Menu
 > Manager.  The popping up of submenus during mouse dragging cannot be
 > controlled directly by the menu definition procedure; the only way to do
 > this in the current system would be to install a vertical retrace task on
 > mDrawMsg that checks to see if conditions are such that a submenu should be
 > brought up or removed, removing it on mChooseMsg.  That would be incredibly
 > kludgy, though not impossible.
 > -=-
 > Tim Maroney, CMU Center for Art and Technology
 > Tim.Maroney@k.cs.cmu.edu	uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim
 > CompuServe:	74176,1360	My name is Jones.  I'm one of the Jones boys.


	Wouldn't it be easy just to rewrite the menu definition
	procedure?  There is one problem though: how do you create
	a "window" (which overlays the other windows on the screen)
	and put the previous stuff back on the screen immediately
	after the "window" is closed (rather than after an update
	event).  This is what happens when you pull down a menu
	in the menu bar - a "window" (or a grafport, or whatever)
	appears to show the items.  Anyway, once we can do this
	ourselves, sub-menus should be easy by just modifying the
	original menu definition.

			Victor Romano
Re: Time for SubMenus [message #224287 is a reply to message #150215] Thu, 31 October 1985 07:42 Go to previous message
tim is currently offline  tim
Messages: 230
Registered: February 2013
Karma: 0
Senior Member
Article-I.D.: k.626
Posted: Thu Oct 31 07:42:27 1985
Date-Received: Sun, 3-Nov-85 12:17:32 EST
References: <3@gumby.UUCP> <610@k.cs.cmu.edu.ARPA>, <1166@sdcsvax.UUCP>
Organization: Carnegie-Mellon University, Networking
Lines: 28

Victor Romano:
 >  Wouldn't it be easy just to rewrite the menu definition procedure?
 
No.  There are three messages to menus, one to draw the whole menu, one to
handle mouse-ups, and one to figure out the menu size.  There's no message
to handle hiliting of a particular item during dragging.  That's why, as I
said, you'd have to use a back door, such as installing a vertical retrace
task that checks the mouse, or patching MenuSelect.  There are no hooks in
the existing Menu Manager (none documented, anyway) that would allow
sub-menus to pop up as you dragged through the menu, the proposed behavior.
 
 >  There is one problem though: how do you create
 >  a "window" (which overlays the other windows on the screen)
 >  and put the previous stuff back on the screen immediately
 >  after the "window" is closed (rather than after an update
 >  event).  This is what happens when you pull down a menu
 >  in the menu bar - a "window" (or a grafport, or whatever)
 >  appears to show the items.
 
That part's easy!  Get a block from the Memory Manager, use CopyBits to copy
from the screen rectangle about to be overdrawn into the heap block, draw
the menu, and when the menu goes away, reverse CopyBits and dispose of the
heap block.  Don't use a new window or grafPort, just the Window Manager
port (saving and restoring the current grafPort, of course).
-=-
Tim Maroney, CMU Center for Art and Technology
Tim.Maroney@k.cs.cmu.edu	uucp: {seismo,decwrl,etc.}!k.cs.cmu.edu!tim
CompuServe:	74176,1360	Religion is a branch of psychology.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: A way to accidentally destroy your disks
Next Topic: OPS5 for the Mac
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Mar 29 08:54:00 EDT 2024

Total time taken to generate the page: 0.10241 seconds