stack not specified height (from using editmenus?)

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com