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