Bob Sneidar wrote: >> On Mar 6, 2015, at 14:51 , Dr. Hawkins wrote: >> It doesn't seem to make sense that a menu on the application/macos >> titlebar would affect the window layout (but if that's >> correct, it's easy enough to adapt to). > > I think it’s wiggy too, until you consider that someone developing > for both platforms would want the same spacial look and feel for both > Win and OS X. Having empty space at the top of an OS X window would > almost always be undesirable.
It can seem "wiggy" if you spend most of your time on Macs so that it may not be readily apparent just how uncommon it is to have a global menu bar. I trust Windows users feel this Mac convention is equally "wiggy". :)
In general GUI terms, a window has two primary regions: the drag region and the content region.
The window's title is drawn in the drag region, while a menu bar is part of the content region.
Menu aren't in the title bar at all. On Mac they're completely disconnected from the window, and for the other 90% of the GUI world they're not in the title bar either but below it.
As a convenience for deploying to Macs, by default the portion of the content region occupied by the menu bar is cropped when rendering the window, and the menus from that group are rendered in the Mac's global menu bar instead.
The portion of the card containing the menu group will only appear empty if you also go out of your way to hide that group, a step normally not needed by virtue of this automatic cropping.
Even then, hiding the group generally won't show an empty area because the window's already cropped. You'd have to go further out of your way to show that to the user by explicitly turning on the editMenus stack property, something you wouldn't normally consider unless you were actually editing the objects in the menu group.
By and large, the default behaviors are pretty good and can usually be left alone for reasonably HIG-savvy deployment across platforms.
One of the few areas where the complete contents of the card may come into play is with printing, and only in certain circumstances.
Given that the layouts in our UI stacks are more frequently set up for user interaction, it's common to have a substack for printing in which the card is sized for the current printer metrics and page orientation, and contains only the elements we want to print.
But sometimes we may want to print the same card we've designed for the user to interact with, and in that case we'll need to take into account everything on the card, which may include a menu bar.
In any layout, if you want to print only a portion of the card you'll want to specify that portion in your print command options.
-- Richard Gaskin Fourth World Systems Software Design and Development for the Desktop, Mobile, and the Web ____________________________________________________________________ [email protected] http://www.FourthWorld.com _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
