Menubar on Windows???

[Richard Gaskin]

xavier.bury wrote:
> While the idea of a floating menubar is really nice (and so NeXT like!), 
> it does pose a few problems on windows:
> 
> - win32 task bar object - rev here is a nightmare - click on one and the 
> menubar still stays behind/hidden for example...
> - If you hide the application, dont forget to hide the menu - but maybe 
> that's not wanted but maybe yes other times
> - submarining the menu as you mentioned - but sometimes it is the other 
> way around. And there's a bug in RR where the palettes are submarined by 
> the normal stacks (fixed in 2.9?)
> - it's not standard and most windows users hate separate menus (as far as 
> i've heard and seen them moan)
> - a separate menu steals more desktop real-estate than an included menu
> 
> There's reasons why it could be cool but when you are used to menus being 
> always on top of the window, you dont have to look for them. 
> The same goes for a Mac user who sees their window while the menu of 
> another application (which is active with no [overlapping] windows) is 
> visible...
> 
> just my two revcents...

I'd say more like a dollar's worth. :) You raise some very valuable 
issues, perhaps most importantly the consistency of the user experience 
for the person running your app in Windows.

Just as Mac users would find it disconcerting to have their menus at the 
top of the window rather than in the menu bar, Windows users are 
accustomed to having menus at the top of their window, and changing that 
long-established convention risks being accused of "a Mac port" (I've 
had that with the one app I still ship which has a detached menu bar).

In that app, we went that route because we had a very Mac Classic 
design, with lots of separate windows providing different views into the 
data.

Since then, software design on the Mac has evolved to favor multiple 
panes in a single window where we used to use multiple windows.  For 
example, in the olden days video editing software commonly had at least 
three windows:  preview, timeline, and clips.  In iMovie and other 
modern apps these are now panes in a single window.  This migration to 
single-window UIs extends to email, iPhoto, tabbed web browsers, and a 
great many others.

With OS X this migration is esp. useful, since Apple has now joined the 
rest of the world with interleaved windows.  In Classic, all windows of 
an app came forward when any of them were clicked, but in OS X (and 
Window, UNIX, Linux, etc.) windows are fully interleaved: bringing a 
window forward only brings that one window forward, and any other 
windows, even those of the same app, are left where they were in the 
stacking order.

This interleaving creates a need for more window management than is 
needed with a single-window UI.  In older-style apps, to see all of the 
data views in various windows one would need to manually bring them all 
forward, or select "Bring All To Front" from the Window menu.  But if 
you migrate those views to multiple panes within a single window, just 
one click brings everything you need to the front.

For us Rev developers, this trend makes it easier to deliver 
HIG-conformant apps for all platforms, since we can make one menu bar in 
our one window and it'll display appropriately on OS X in the menu bar 
and at the top of the window for all other OSes.

But sometimes redesigning a multi-window app to a single-window one is 
challenging and will require some thought to how the panes are laid out. 
So while prepping for a future single-window version, there are a couple 
things that can be done to make a detached menu bar slightly less 
cumbersome on Windows:

In addition to adjusting the windowBoundingRect noted in my last post, 
there's also the minimize behavior.  For that we trap the iconify 
message in the mainStack, and when the window being iconified is the 
menu bar we iconify all stacks.  Similarly, when any stack is 
uniconified we make sure the menu bar stack is uniconified as well.

But tossing in my own $0.02, I would encourage those making apps with 
detached menu bars to consider migrating to a design which supports the 
Windows convention of having the menu bar at the top of the window. 
While a quickie Mac port can get away with a detached menu bar for a 
first version, to be successful on Windows you'll want to adopt standard 
Windows conventions.

And in the long term, if your app uses multiple windows you may find you 
can simplify your menu work while you simplify the user experience by 
migrating to multiple panes in a single window instead.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com