[comp.sys.amiga.tech] YAWS

u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) (06/18/88)

Since everyone is putting in their suggestions for worbench wonders they
would like to see, how about making menus really recursive instead of only
two levels deep.  It seems like this would be reasonably easy to do, and
would make for really useful :^) 45 level menus and such.  Sure, it would
take a bit of care to make all those sublevels easy to find, and not go
off the edge or bottom of the screen, but it would add quite a bit of 
flexibility to the interface.  This would also make it easier to include
the interfaces to currently running programs (like the discussion about
those silly extra windows all over the place).

All you would need was one menu for external programs, where each top level
entry would be a program name which could have an entire menu subsystem
arranged vertically instead of horizontally on the program's "main" level.

I haven't looked at a menu structure recently (I'm at work now) but it seems
that the pointers are all there and it's just WorkBench that isn't being
freindly about it.

"To iterate is human.  To recurse, divine." -unknown

 /|  |     /|||  /\|		|	John M. Olsen, 1547 Jamestown Drive
 \|()|\|\_  |||. \/|/)@|\_	|	Salt Lake City, UT  84121-2051
  |	u-jmolse@ug.utah.edu	or  ...!ihnp4!utah-cs!utah-ug!u-jmolse
"What is mind?  No matter.  What is matter?  Never mind."  -T. H. key

mp1u+@andrew.cmu.edu (Michael Portuesi) (06/19/88)

> *Excerpts from ext.nn.comp.sys.amiga.tech: 17-Jun-88 YAWS (Yet Another*
> *Workbench.. John M. Olsen@utah-gr.UU (1333)*

> Since everyone is putting in their suggestions for worbench wonders they
> would like to see, how about making menus really recursive instead of only
> two levels deep.

Well, this is really an enhancement for Intuition, not Workbench.

> All you would need was one menu for external programs, where each top level
> entry would be a program name which could have an entire menu subsystem
> arranged vertically instead of horizontally on the program's "main" level.
I don't understand what you are saying.  Are you implying that other programs
should be allowed to place their menulists in the menulist for the Workbench
window?  If so, that is not the same thing as allowing n-level nested menus.

> I haven't looked at a menu structure recently (I'm at work now) but it seems
> that the pointers are all there and it's just WorkBench that isn't being
> freindly about it.

I'm pretty sure that the SubMenuItem structures do not have a pointer in their
fields to hang more SubMenuItems onto.  It wouldn't have been too difficult to
do this initially...I suspect the decision to allow only one level of nesting
was deliberate.

More disturbing is the limitation on the number of items that can appear on a
Workbench menu.  The browser option in MG has gone nuts on directories
containing too many files to fit in one menu.  Also, the menus do not scroll if
they are too large for the screen, and menus that go off the right edge of the
screen are not clipped; they simply wrap-around onto the left hand side,
causing some really unsightly effects.  It does not look like allowing more
items on a menu is feasible, though, as that would involve changing some fields
in the Menu structure that would probably break a great many programs (like
just about all of them).

                        --M


Michael Portuesi / Information Technology Center / Carnegie Mellon University
ARPA/UUCP: mp1u+@andrew.cmu.edu                     BITNET: rainwalker@drycas

"if you ain't ill it'll fix your car"

u-jmolse%sunset.utah.edu@utah-gr.UUCP (John M. Olsen) (06/20/88)

In article <gWipIgy00Vs6M48V01@andrew.cmu.edu> Michael Portuesi writes:
>> *Excerpts from ext.nn.comp.sys.amiga.tech: 17-Jun-88 YAWS (Yet Another*
>> *Workbench.. John M. Olsen@utah-gr.UU (1333)*
>> Since everyone is putting in their suggestions for worbench wonders they
>> would like to see, how about making menus really recursive instead of only
>> two levels deep.
>Well, this is really an enhancement for Intuition, not Workbench.

Whatever can get it done. :^)

>
>> All you would need was one menu for external programs, where each top level
>> entry would be a program name which could have an entire menu subsystem
>> arranged vertically instead of horizontally on the program's "main" level.
>I don't understand what you are saying.  Are you implying that other programs
>should be allowed to place their menulists in the menulist for the Workbench
>window?  If so, that is not the same thing as allowing n-level nested menus.

Sorry, I merged two topics without warning.  What I meant to say is that you
could keep menus working in the normal way they do now, but also add a 
feature to allow for programs to tap into a special new workbench menu item,
called RESIDENT or some such, where a program could install it's own menus
if it has no window to attach them to.

>
>> I haven't looked at a menu structure recently (I'm at work now) but it seems
>> that the pointers are all there and it's just WorkBench that isn't being
>> freindly about it.
>
>I'm pretty sure that the SubMenuItem structures do not have a pointer in their
>fields to hang more SubMenuItems onto.  It wouldn't have been too difficult to
>do this initially...I suspect the decision to allow only one level of nesting
>was deliberate.

I hate it when someone (deliberately or accidentally) removes flexibility.
I looked at intuition.h, and it looks like the structures could handle it
just fine.  Each MenuItem has a pointer for the item below it, and another
pointer for the sub-items.  The top level Menu structure is just a linked
list of pointers to MenuItems, with a few extra doodads like menu names.
It would only be necessary to define a new type of Message where you could
return what was selected since the current method only likes two level menus.
(correct me if this is a hallucination)  Then we could see how much more 
confused everyone gets when dealing with menus.  It would still be up to the
programmer to not make spaghetti menus, just as it is now necessary to check
for good positioning and not-too-long dynamic lists.

>More disturbing is the limitation on the number of items that can appear on a
>Workbench menu.  ...

It would be nice if there were a way to do it.  Menus could be perverted into
doing that by having MenuItems like "fonts a-e", "fonts f-j", "fonts k-o",
and then having each of them be loaded to the gills with entries.  This
would even work with the way it's set up now.  Of course it would have to be
dynamic and adjust as it read font names until you maxed out at about 400
fonts or so, which I doubt would be a problem. :^) (20 items on the first 
level, each with 20 sub items).

>                        --M
>Michael Portuesi / Information Technology Center / Carnegie Mellon University
>ARPA/UUCP: mp1u+@andrew.cmu.edu                     BITNET: rainwalker@drycas
>"if you ain't ill it'll fix your car"


 /|  |     /|||  /\|		|	John M. Olsen, 1547 Jamestown Drive
 \|()|\|\_  |||. \/|/)@|\_	|	Salt Lake City, UT  84121-2051
  |	u-jmolse@ug.utah.edu	or  ...!ihnp4!utah-cs!utah-ug!u-jmolse
"What is mind?  No matter.  What is matter?  Never mind."  -T. H. key