United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6492110 GTK L&F: JMenuBar is taller than native under Clearlooks
JDK-6492110 : GTK L&F: JMenuBar is taller than native under Clearlooks

Details
Type:
Bug
Submit Date:
2006-11-10
Status:
Closed
Updated Date:
2011-03-09
Project Name:
JDK
Resolved Date:
2011-03-08
Component:
client-libs
OS:
solaris_9
Sub-Component:
javax.swing
CPU:
generic
Priority:
P4
Resolution:
Fixed
Affected Versions:
6
Fixed Versions:

Related Reports
Backport:
Relates:

Sub Tasks

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.)
                                     
2006-11-10



Hardware and Software, Engineered to Work Together