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.
Summary: | On Mac OS menubar should be on top of the screen | ||
---|---|---|---|
Product: | platform | Reporter: | ajmas <ajmas> |
Component: | Window System | Assignee: | Milos Kleint <mkleint> |
Status: | VERIFIED FIXED | ||
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
Does this work in 4.0 yet Tim? Nope. Maybe if there's time... -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. 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. *** Issue 52696 has been marked as a duplicate of this issue. *** 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
}
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 :-) *** Issue 57796 has been marked as a duplicate of this issue. *** -J-Dapple.laf.useScreenMenuBar="true" works but accelerators aren't displayed in main menu bar. Doesn't Netbeans use standard accelerators for menus ? *** Issue 59307 has been marked as a duplicate of this issue. *** works on branch APPLE_MENU_39449 fixed in trunk. will be part of 20050714 daily build. on macosx the top-menu is the default now. verified in NB 5.0 - RC2 This issue had *2 votes* before move to platform component |