Portable GUI levels (was: Re: [GUI] Re: Gtk and Object I/O)

[Wolfgang Thaller]

Glynn Clements wrote:

> [...] If the OS allows the application to change the menubar 
> dynamically,
> then you can change it whenever the "active" window (e.g. the one with
> the keyboard focus) changes. This is what Tk does for MacOS:
> [...]

> The main factor for ensuring portability is not to assume that a
> menubar is just another widget [...]

All that you say is true, but...
I'm not concerned about whether it will be implementable on Mac OS
(it most definitely will be), but whether it will _feel_ right. This 
standard
approach (the one used in Tk), violates the following "holy laws" of the
Mac OS look & feel;

a) Mac programs are simply not supposed to switch menu bars. It will
confuse or at least annoy users. On Mac OS, the menu bar tells you
which application is currently active - if it changes inside one 
application,
that application will feel like one-and-a-half applications, novice
users will get lost, and seasoned users will get annoyed.

b) There still should be a menu bar when no window is around.

The behaviour of a Mac OS application is similar to a Windows MDI
application whose MDI frame window has been maximized to fill the
screen.
On Windows, when you switch between MDI child windows, the menu
bar of the frame window doesn't change, and when you close the last
child window, the frame window doesn't close.

I maintain that a good cross-platform toolkit designed for Windows,
X11 and Mac OS should provide some abstraction to bridge the
differences in the behaviour of the different platforms.
If I remember correlctly, Tk, Java and Qt were all first designed for
X11 and then ported to Windows and Mac OS. Hence they had to
use the "let's use the front window's menu bar" hack for Mac OS.

Cheers,

Wolfgang