Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 6492110
Votes 0
Synopsis GTK L&F: JMenuBar is taller than native under Clearlooks
Category java:classes_swing
Reported Against
Release Fixed 7(b07), 6u1(b01) (Bug ID:2144186)
State 10-Fix Delivered, bug
Priority: 4-Low
Related Bugs 6465603
Submit Date 10-NOV-2006
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.
Posted Date : 2006-11-10 01:53:05.0
Work Around
N/A
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.)
Posted Date : 2006-11-10 10:00:41.0
Comments
  
  Include a link with my name & email   


PLEASE NOTE: JDK6 is formerly known as Project Mustang