JDK-6492110 : GTK L&F: JMenuBar is taller than native under Clearlooks
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: generic
  • Submitted: 2006-11-10
  • Updated: 2011-03-09
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u1Fixed 7 b07Fixed
Related Reports
Relates :  
JDK-6465603 - GTKLAF: Menu item selection bar hieght is not consistant in the menu and popupmenu across the items.
Description
The JMenuBar container is 4 pixels taller than native under the Clearlooks theme
(or any other theme that uses the clearlooks engine).  Use the attached
JavaWidgetFactory and native "twf" testcase to compare.  It's interesting that this
problem isn't seen in other themes/engines, so I'm guessing that we're picking up
extra padding in the insets under Clearlooks that we wouldn't otherwise.
Comments
EVALUATION This is actually a kind of regression caused by the recent putback for: 6465603: GTKLAF: Menu item selection bar height is not consistant in the menu and popupmenu The overall menubar height is now much taller because of this change in the GTKStyle constructor: int thicknessWidgetType = ((widgetType == WidgetType.MENU_BAR || widgetType == WidgetType.MENU) ? WidgetType.MENU_ITEM : widgetType).ordinal(); Previously we only applied this special case for MENU_BAR, but now we are doing it for MENU as well. I don't quite understand the purpose for special casing of MENU_BAR and MENU in the first place. If you look at the source code for gtkmenubar.c, gtkmenu.c, and gtkmenuitem.c (in their *_size_request()) methods, you will see that each has its own way of calculating the size. But in GTKStyle, we pipe all requests for getInsets() to the same getMenuInsets() method. This means that even prior to this regression, we were often getting the wrong menu sizes compared to native anyway. After some searching, I think the reason we have a special case here at all is because in Swing there is a hierarchy: a JMenuBar will have one or more JMenus as its children. JMenus can have JMenuItems and/or JMenus as its children. In GTK speak, a GtkMenuBar will have GtkMenuItems as children. GtkMenuItems can have GtkMenuItems as children, and so on. So in GTK land, there's really no distinction: GtkMenuItems can be standalone, or they can have submenus. As far as I can tell, GtkMenu is more akin to JPopupMenu (it is a container for menu items). So the reason for the special case is to treat JMenus as if they are like JMenuItems, for the purposes of mapping to a native GTK widget. But I don't think it makes sense to have this special case in the GTKStyle constructor. Instead, why not simply map WidgetType.MENU to GtkMenuItem? In other words, just treat MENU and MENU_ITEM the same for the purposes of wiring up to native GTK components. For the purposes of calculating insets, we should have two methods: getMenuBarInsets() and getMenuItemInsets(), since the calculations are slightly different. In summary: JMenuBar -> GtkMenuBar JMenu -> GtkMenuItem JMenuItem -> GtkMenuItem JPopupMenu -> GtkMenu With these changes in place, we have proper menu bar/item sizing that exactly matches that of native applications, under all themes. (The layout of menu item content is still very quirky, but that will be dealt with under a separate bugid.)
10-11-2006