This change would allow users to hit "mile high" menus in the menu
panel, marking Usability.

Just out of interest, why do we have borders when the shadow is on? We
want the target area to be as large as possible.....

Wed Feb 27 14:58:12 2002  Owen Taylor  <otaylor@redhat.com>

        * gtk/gtkmenubar.c (gtk_menu_bar_size_request/allocate): 
        Don't reserve space for border when the shadow type
        for the menubar is "none". (#61843)

        * gtk/gtkmenubar.c (gtk_menu_bar_size_allocate): Fix
        offset for right-justified menu items.

With this change if you set the ::internal-padding style property
to zero and the shadow type to none, then you can click all the 
way to the edge.

Leaving open on future milestone to consider issues of:

 - Whether we should put the internal padding inside the menu
   items instead of outside.
 
 - Whether we should put the menu items over the bevel (we do
   this for GtkToolbar.)

> - Whether we should put the menu items over the bevel (we do
>   this for GtkToolbar.)

I think this would be great!

You can see an "after" pictured on this page which I made for
another bug report:

  http://www.phys.lsu.edu/~merchan/CGMenus/index.html

This looks sweet.  
If i understand this correctly with this patch i will be able to put
the menubar right up against the top edge of the screen and only need
to aim horizontally somewhat like on an Apple Mac.  

I am not sure but this might also be helpful to the people concerned
by bug 104549
http://bugzilla.gnome.org/show_bug.cgi?id=104549

should i add the PATCH keyword? (and attach the patch that was mailed
to the list?)

I think we should put the ipadding inside the menu item. Trivial patch
for that coming up.

For the second one, how about adding a

     _gtk_menu_item_set_active_border (menu_item, left, right, top,
bottom);

that would make the menu item make their windows this amount bigger?
That way the menubars and the menus could make the active area of
their children cover the bevels.

Created attachment 17961 [details] [review]
The trivial patch

I'd like this to be considered for 2.4.0

Shouldn't the width/height of the child be increased as well?

As for the "active border" idea, there are some compatibility
issues there - I suspect there are custom menu item subclasses
with custom size allocation functions.

I don't have a good solution for that - the problem is that
these custom subclasses inherit from GtkMenuItem, so almost
anything we do to mark the menu item as "supports active border"
will get inherited as well.

And of course, you *want* that property to be inherited in
most cases of derivation (Especially for something like 
gtkmm's's null derivation.)

I think, as ugly as it sounds, the best way to make the bevel
active for GtkMenuBar and GtkMenu is to handle the mouse
events on the bevel in the GtkMenu/GtkMenuBar code, rather
than trying to expand the menu items' event window to cover
the bevel.

> Shouldn't the width/height of the child be increased as well?

Well, the height does actually get increased because it is calculated
by subtracting 2 * y from the menu height. 

The problem with increasing the width is that menu items don't center
themselves, and it isn't obvoious to me how they could, given that
they may have icons, that they should keep the text labels left
aligned, and that they don't know the size of the ipadding. So the
patch ignores ipadding in the horizontal direction.

Handling mouse events on the border and passing them on to the menu
item sound like it would be difficult to get right given the current
event mechanisms in the menu system. But probably doable by someone
sufficiently determined.

*** Bug 128077 has been marked as a duplicate of this bug. ***

*** Bug 128077 has been marked as a duplicate of this bug. ***

*** Bug 128077 has been marked as a duplicate of this bug. ***

*** Bug 128077 has been marked as a duplicate of this bug. ***

I have committed a change that puts vertical, but not horizontal,
ipadding into the menu item.

Leaving this bug open on "future" to track the issue of making the
bevels active.



Thu Feb 26 23:26:00 2004  Soeren Sandmann  <sandmann@daimi.au.dk>

	* gtk/gtkstatusbar.c (set_grip_cursor): New function. Use resize
	cursors for resize grips. (Bug #129621)

	* gtk/gtktoolbar.c (gtk_toolbar_get_relief_style): Documentation
	fix - patch by Torsten Schoenfeld.

	* gtk/gtkmenubar.c (gtk_menu_bar_size_request): don't request
	space between the items. (Bug #110775)

	* gtk/gtkrc.c (_gtk_rc_init): Provide extra horizontal padding
	inside menu items that are inside a menu bar. (Bug #110775)
	
	* configure.in (HAVE_XCURSOR): Make XCurosr part of GDK_EXTRA_,
	not GDK_PACKAGES, to prevent applications from getting linked to
	it (Bug #119804)

	* gtk/gtkmenubar.c (gtk_menu_bar_size_allocate): Put the vertical
	ipadding inside the item. (Bug #61843)

Bug 149257 is requesting quite the opposite, to not dismiss the menu when
clicking on the border area.

The behavior discussed in this bug makes sense for gnome-panel type menus that
are next to screen border, but IMHO not so much for application or context menus
that are generally away from the screen border.

closing out old bugs