Menu woes

[Richard Gaskin]

Frank Leahy wrote:
> On Dec 30, 2004, at 5:00 PM, use-revolution-request at lists.runrev.com wrote:
> 
>> From: Richard Gaskin <ambassador at fourthworld.com>
>> Subject: Re: Menu woes
>> To: How to use Revolution <use-revolution at lists.runrev.com>
>> Message-ID: <41D4278D.6010701 at fourthworld.com>
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>
>> Frank D. Engel, Jr. wrote:
>>
>>> I suspect the easiest way to "fix" the menu issue and maintain some of
>>> the current flexibility would be:
>>>
>>> 1. Keep the system as it is, for the most part.
>>> 2. When using a group as the Mac menu bar, do not scroll the stack.
>>> 3. When using a group as a menubar in the window, scroll and enlarge the
>>> stack.  Now the rect of the card (for ex.) would have a negative minimum
>>> vertical coordinate, since the menus would stop before reaching zero.
>>>
>>> Of course, this would break backward compatibility somewhat, but not
>>> nearly so much as some of the other proposals, and yet this would fix
>>> some of the other problems which have been mentioned here...
>>
>>
>> I don't understand:  as I read that it seems to suggest that all we do
>> is switch the scrolling from Mac to all other OSes, so that instead of
>> the scroll taking place on 2.4% of computers it takes place on 97.6%.
>>
>> Remember that having the menubar be part of the window rather than
>> detached is how every modern OS works except Mac.  We could debate the
>> efficacy of that (Tog has a lot to say in favor of a detached menu bar),
>> but it won't likely change how Windows, GNOME, KDE, X11, and all other
>> non-Mac windowing systems work.
> 
> 
> Having the menu area a separate section of the stack, just like the 
> window title is, would solve the problem.  No scrolling problems, no 
> resizing problems.

But the OS takes care of the title bar, while Rev would need to invent a 
new type of object to embed a menu bar on a stack but outside of the 
stack's card.

This might be a good case for viewer objects, a type of object in 
RADBuilder (formerly Gain Momentum) that lets you display any stack in a 
specified rectangle within any other stack. (There once was a Bugzilla 
request for this, but alas I can no longer find it).

But whether the menubar is on the card or in a viewer, the total height 
of the window still needs to be adjusted to accomodated it. What should 
querrying the stack height return?  Wouldn't it be different from the 
card height on Win as it is on Mac now?

I love my Mac and use it for most of the development cycle, but I'm also 
first in line to recognize marketshare position and contain efforts to 
deal with any anomalies unique to it to that camp.

But more to the point, consider the interface Chipp was building that 
started this thread:  he posted because he wanted to include controls 
for the main window in the menu bar region; the proposed mechanism would 
make that impossible, while it was simple for him to finish it with the 
current mechanism in just two lines.

If he wanted to have the menubar completely separate from all other 
controls that already happens automatically; he wouldn't have needed to 
post, and we wouldn't be having this conversation exploring alternatives. ;)

> By the way, Tog did that "research" he keeps talking about at Apple 
> pre-1986 (when I got there), on a 9 1/2 inch original Mac screen.  His 
> results aren't applicable to 1) larger screens, 2) multiple monitors, or 
> 3) doing fine detail work in programs such as photoshop which use 
> tearoff menus to advantage, allowing you to move the menu close to the 
> area you're working in.

True, but the core question is whether the "backstop" effect of the 
monitor bounds offsets the distance-to-target cost.

Sadly, I can find no recent research published either Microsoft or Apple 
on the subject.  It seems the days when OS vendors demonstrated the 
efficacy of their designs by publishing their research methodologies are 
long gone, leaving the door open to accusations that usability research 
teams have been replaced by graphic artists.

But you may well be right, and perhaps there is a good argument for 
Apple to catch up to all other OSes with regard to menu bar placement. 
Good luck getting them to consider such a change. ;)

-- 
  Richard Gaskin
  Fourth World Media Corporation
  Developer of WebMerge: Publish any database on any Web site
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com