On Dec 30, 2004, at 5:00 PM, [EMAIL PROTECTED] wrote:
From: Richard Gaskin <[EMAIL PROTECTED]> Subject: Re: Menu woes To: How to use Revolution <[email protected]> Message-ID: <[EMAIL PROTECTED]> 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 ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
