🚀 go-pugleaf

In article <588@sunfs3.camex.uucp>, kent@sunfs3.camex.uucp (Kent Borg) writes:
>In article <2964@pur-phy> cca@pur-phy (Charles C. Allen) writes:
>>[describes menu in a window, possibly/probably wrapped for size]

>But we would loose an important feature of the current menus.  People
>can scan through the current menu bar by dragging left and right, and
>select from within a menu be dragging down and up.  If you wrap the
>menu bar, you can't do this.  It might sound trivial, but a lot of
>what makes the Mac so great sounds trival.

  Drag down-left doesn't open/leave open the menu, same as drag-down
doesn't leave hierchical menus open.  Drag-down or down-right puts you
"in" the menu and leaves it open.

  What makes the Mac so great is all the attention paid to all the things
that seem trivial.  10,000 pennies is a $100, any one penny is insignificant,
but they add up.

>I agree that the menu bar can get pretty far away (I wish I had more
>experiance with the problem--anyone want to send me a free big screen
>so I can be more authoratative?), and I agree that presto-chango
>nature of the current menu bar under MultiFinder is confusing.

  I'll take pop-ups and a second mouse-button myself.

  An INIT to put menus in a window shouldn't be too difficult.  A little
work on the window manager and default WDEFs to make "inMenuBar" come from
the WDEF instead of the window manager, the app will still call the Menu
Manager.  A little kludge to re-find the window (since only the cursor is
passed to the Menu Manager, not a Window handle) and maybe the addition of
a Menu handle to a window object (so that menus are window-tied and not
application-tied.)  [What about custom WDEFs?  Long Term: definition of how
to interface to the Menu Manager from a WDEF.  Short Term: a kludge to add
the menu above the drag bar (ick) or a separate modeless vertical menu
window (maybe we should skip the whole menu-in-window bit :-) ]

  As I mentioned, I'll take pop-ups.  But I think the original decision for
a menu-bar, on the assumption that only one program was running, was to make
it always there and easy to get to.  Now that multiple apps are running, I
think putting it in the window is best to acheive the same ease-of-use and
"always there" feeling.

  On the always there feeling, and keeping the one button mouse, and having
pop-ups, and not using screen real-estate, I haven't heard any mention of a
"Menu Region" in the title bar.  This would be fairly large control, about
two to three times the width of a scroll bar and almost the height of the
title, that produces a vertical (or pie for you power users :-) pop-up.
Command-click or second button would be a short-cut and produce the menu
"here" instead of "there".  (Note that command-click is style-guided for
disjoint text selection (does anyone use that?) and is surely used
elsewhere.)

  Currently defined pop-ups are style-guided mainly for item selection, and
in doing define that the menu comes up with the current item under the
cursor.  Pop-up generic menus would most likely appear with the cursor to
the left of the second to fourth item (contrast this with the style-guide,
on pull downs, the second is the easiest to hit).  Very nicely, this would
put the "Edit" just above the cursor and the first and second items of the
App's menus to the right and just below the cursor.

>Another problem: What if an application has more than one window open?
>Do they all have the same menu?

  That's not a problem, that's a solution!  Document windows are almost by
definition different contexts, the set of checked, enabled/disabled,
and show/hide items are different.

>  Do different types of windows have
>different menus (making them look like different apps)?  Is there a
>master window which has the single menu bar?

  1. Yes, 2. No.  Documents are documents.  Layering, I understand, is a hack
for applications that have tool or object attributes windows that are
associated with the document window.  I assume it was a choice of layered
apps or losing the tool windows in the shuffle.

  There should be a way to make documents "layer aware".  So for (2) you
could have one modeless menu, tool, or object window always pulled to the
front _with_ a document that uses it.  But the other documents would not be
pulled.  Documents are different conceptual objects.  I guess what I'm
saying is that a document is tied to a menu or toolchest, but documents
aren't tied together by an "application".

>Another problem: If the menu bar is no longer at the edge of the
>screen, the user can no longer use the top of the screen as a
>backstop.  It becomes possible to overshoot.  Sure, that is true all
>over the rest of the screen, but it should still be understood before
>things are changed.

  Valid point.  But it can be compared to the tiny close box or the drag
region, as you mention.  Once the menu is clicked it would have a slopRect
like that of scroll-bars.  A precise click to start it, but all the
looseness in mouse waving you need to look at the menus afterwards.

  -- Ken

[PS.  I'm in need of a job.  I'm looking for work in advanced technology,
system software, language, and interface design.  If the above kind of
design thinking, tied with the ability to implement it, interests you,
contact me at +1 801 255 3607, +1 801 269 0569, or ken@i-core.uucp.  Have
Mac, will travel.]
-- 
Ken MacLeod, Barkeep
Bitsko's Bar & Grill BBS, +1 801 269-0670
ken@i-core.uucp