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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
