This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 39449

Summary: On Mac OS menubar should be on top of the screen
Product: platform Reporter: ajmas <ajmas>
Component: Window SystemAssignee: Milos Kleint <mkleint>
Severity: blocker CC: ibrandt, jchalupa, shura, ttran
Priority: P3 Keywords: UI
Version: 3.x   
Hardware: Macintosh   
OS: Mac OS X   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 37771    
Bug Blocks:    

Description ajmas 2004-01-31 18:41:40 UTC
From a MacOS X perspective the menu bar is in the wrong 
place. When selecting the Aqua L&F, the menu bar is in the 
window and not at the top of the screen where it is 
expected. This does not follow UI guidelines and doesn't 
feel right from a usage perspective. Whatever OS a Java app 
runs under, it should look as much as possible as if it were 
designed for it, or at least give that illusion.
Comment 1 Jesse Glick 2004-07-24 19:57:21 UTC
Does this work in 4.0 yet Tim?
Comment 2 _ tboudreau 2004-07-24 21:50:24 UTC
Nope.  Maybe if there's time...
Comment 3 ibrandt 2004-12-03 20:32:07 UTC
-J-Dapple.laf.useScreenMenuBar="true" is working fairly well for me on
4.0 RC2.  I've tried both SDI and MDI mode.

In either mode the Versioning menu's CVS and PVCS sub-menu's are missing.

In SDI mode the menu bar is only there when the main tool bar frame is
active.  It would be nice if it was there for all Netbeans frames. 
Also the main tool bar frame's default size is too tall, not taking
into account the missing menu bar.  It can be resized by the user, and
the new size is remembered on consecutive start-ups.  So I wouldn't
say either of the SDI specific issues that I'm seeing are show-stoppers.

With the larger, bolder text the native menu bar sure is nice,
especially if you're used to it being there for Mac apps.  Are there
any other known issues holding this back?  If it's only the Versioning
sub-menus problem I might be able to find time to look into that one.
Comment 4 _ tboudreau 2004-12-04 11:34:03 UTC
Fixing this requires a rewrite of a fairly vast, knotty mess of circa 1998/9 menu code that's 
very hacky, and in some cases involves classes that are part of public API but simply 
cannot work on mac os, with the way the screen menu bar behaves.

FWIW, Apple did offer to try to fix it on their side if we could give them a stripped down 
application that does all the evil things NetBeans menus do (such as a JMenu which 
sometimes has the UI delegate of JMenuItem, sometimes that of a JMenu).  I'm not sure it's 
reasonable to ask anyone to support the psycho stuff that NetBeans menus do.

At any rate, reassigning to Milos, who has taken over mac issues in NetBeans - I know he's 
already at least looked at a fix for JInlineMenu.  Probably a proper fix will involve breaking 
compatibility, or at least eliminating all uses of JInlineMenu and Actions.SubMenu in 
NetBeans and deprecating them with a very stern warning.

The stuff in contrib/menus could be interesting - it's a bridge which uses a TreeModel to 
define the menu structure;  one TreeModel can be written for the old actions/menus API, 
and another TreeModel for a better replacement (which we know we need);  a merged 
TreeModel can then be used for cases where there are some legacy items.  It has a load of 
unit tests for all the sorts of things NetBeans does, all of which pass both with and without 
the screen menu bar on MacOS.  It would be a good place to start.
Comment 5 _ ttran 2005-03-21 21:29:42 UTC
*** Issue 52696 has been marked as a duplicate of this issue. ***
Comment 6 _ ttran 2005-03-21 21:33:29 UTC
From Tim Boudreau's email:

> what's exactly is the issue?  JInlineMenu only or something else?  Tim,
> you told me that an Apple engineer gave you a hint.  what's exactly?

A few things:
 - JInlineMenu, to dynamically update its contents, relies on a call which is
made every time a Swing menu is posted, createPopupMenu() I think, but which is
only made when the menu is first added when using the screen menu bar.  Fix is
to listen on the ButtonModel for the menu instead of createPopupMenu().  Gets
really ugly with nested JInlineMenus, which VCS used last I knew.

 - Actions.SubMenu - the following code will not work (not to mention being a
satanic hack):

        public String getUIClassID () {
            if (previousCount == 0) {
                return "MenuItemUI"; // NOI18N
            return previousCount == 1 ? "MenuItemUI" : "MenuUI"; // NOI18N
Comment 7 _ ttran 2005-03-21 21:34:49 UTC
More from Tim:

Take a look at contrib/menus.  It contains the following:
 - A module which implements a menu bar based on a TreeModel containing random
objects, and a Looks-like infrastructure to map objects to components, with an
SPI for that model
 - A looks-like implementation which allows components to be updated when a menu
is posted (if an offline change happens, it's just setting a dirty flag)
 - A ton of unit tests for the dynamic modification functionality, which pass
nicely both on the screen menu bar and vanilla Swing
 - A submodule (unfinished) which implements the TreeModel in question as a
bridge to existing registered actions

May not be what you want to use, although this would allow you completely
replace NB's action registration mechanism and still have legacy actions work. 
At any rate, look at how the dynamic menu code works - it does everything
NetBeans needs and *does* work in both places and has tests to demostrate that.
 Not polished, but possibly a good starting point.

It's also the only code that I've ever written that has a variable called
operacniStolek :-)
Comment 8 puybaret 2005-04-15 09:11:07 UTC
*** Issue 57796 has been marked as a duplicate of this issue. ***
Comment 9 puybaret 2005-04-15 09:21:59 UTC
-J-Dapple.laf.useScreenMenuBar="true" works but accelerators aren't displayed in
main menu bar. Doesn't Netbeans use standard accelerators for menus ?
Comment 10 Milos Kleint 2005-05-27 14:06:48 UTC
*** Issue 59307 has been marked as a duplicate of this issue. ***
Comment 11 Milos Kleint 2005-06-30 11:08:25 UTC
works on branch APPLE_MENU_39449
Comment 12 Milos Kleint 2005-07-14 08:50:42 UTC
fixed in trunk. will be part of 20050714 daily build.
on macosx the top-menu is the default now.
Comment 13 Marian Mirilovic 2006-01-18 15:48:20 UTC
verified in NB 5.0 - RC2
Comment 14 Quality Engineering 2008-12-23 14:22:18 UTC
This issue had *2 votes* before move to platform component