When the menu is detached, the attach-widget property changes value to
NULL, so we should notify a property change, like
gtk_menu_attach_to_widget() does.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
This was broken since before GTK+ 3.0, when we replaced
a use of requisition by allocation. Fix this by using the
requisition height, that is already cached by the menu code.
The math is not quite right here; if you page all the way
down a long menu, you end up on the second-to-last menuitem.
But at least, page up/down let you move up and down the menu
again.
https://bugzilla.gnome.org/show_bug.cgi?id=668931
Add an internal API that allows GtkStyleContext to create a widget path
for the widget and with that bypassing gtk_widget_get_path() and that
function caching the path.
This is so submenus stay open as the parent menu item is
pressed/released, since the user would typically lift the
finger in order to select a submenu item.
If the display server or GDK hides the window - fire the "deactivate" signal
to ensure that the internal state is consistent.
This patch also ensures that the "deactivate" signal will not be fired for a
menu that is not active.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=670881
gtk_window_get/set_attached_to() is a new API that allows for windows to
be attached to a GtkWidget.
The attachment is a logical binding between the toplevel window and the
widget that generated it; this kind of information is currently used to
propagate style information from the widget to the window, but is also
useful e.g. for accessibility.
https://bugzilla.gnome.org/show_bug.cgi?id=666103
The code for moving the menu into monitor / workarea was duplicated,
once for the push-in scenario and once for without. The problem with
the second case is that we've stored the menu position before adjusting
it. That made us remember an out-of-monitor position that then later
triggered _another_ copy of this code in the size-request implementation.
Unify this to only have one copy of code, and only store the menu
position after adjusting it to be inside the monitor. This fixes both
statusicon menus that get popped up from the panel, outside the workarea,
to not have scroll arrows, and the gedit language menu which was not
placed in the monitor at all after the initial workarea commit.
As a side-effect of this change, we now make large scrolling menus
occupy the full height of the workarea. Before this change, we were
keeping either the top or bottom edge put while shrinking the menu
to fit in the monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=667249
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
We want the menu realized so we know the size it's allocating to itself.
And we need that size to position the menu properly.
This is best visible on right-to-left.
Lots of code calls gtk_menu_popup() and we don't want to resize the
window needlessly.
In this particular case, keyboard navigation to submenus caused those
submenus to shrink.
Note: I'm not sure this fix doesn't have nasty side effects, as I'm not
a specialist on menu popup code, so if it does, we'll need to revert it.
Until then, let's keep it, it fixes a bug.
This change does not introduce any functionality change, mostly
cosmtic cleanups, like re-linebreak when introduced annotations messed
up indentation or whitespace errors fixes.
The show_submenu_indicator flag was explicitly set in various
places from GtkMenu/GtkMenuBar at request times, since the
GtkMenuItem already checks the parent type for GTK_IS_MENU_BAR()
in various places, removed this flag in favor of just checking
the parent type (only in the interest of better readable code).
All current users of this CSS property have been updated to deal
with a GtkBorder.
Also a 0 border width has been set in the default CSS to ensure
GtkStyleContext and GtkThemingEngine always provide a non-NULL
pointer for this property.
Some GtkSettings property are registered by other classes. This leads
to the "interesting" issue that setting GtkSettings:gtk-button-images
requires that the GtkButton class is referenced first - or that a
GtkButton is created.
https://bugzilla.gnome.org/show_bug.cgi?id=632538
It doesn't make sense to keep them separate as GtkSizeRequest requires a
GtkWidget and GtkWidget implements GtkSizeRequest, so you can never have
one without the other.
It also makes the code a lot easier because no casts are required when
calling functions.
Also, the names would translate to gtk_widget_get_width() and people
agreed that this would be a too generic name, so a "preferred" was added
to the names.
So this patch moves the functions:
gtk_size_request_get_request_mode() => gtk_widget_get_request_mode()
gtk_size_request_get_width() => gtk_widget_get_preferred_width()
gtk_size_request_get_height() => gtk_widget_get_preferred_height()
gtk_size_request_get_size() => gtk_widget_get_preferred_size()
gtk_size_request_get_width_for_height() =>
gtk_widget_get_preferred_width_for_height()
gtk_size_request_get_height_for_width() =>
gtk_widget_get_preferred_height_for_width()
... and moves the corresponding vfuncs to the GtkWidgetClass.
The patch also renames the implementations of the vfuncs in widgets to
include the word "preferrred".
The keysyms create a lot of potential namespace conflicts for
C, and are especially problematic for introspection, where we take
constants into the namespace, so GDK_Display conflicts with GdkDisplay.
For C application compatiblity, add gdkkeysyms-compat.h which uses
the old names.
Just one user in GTK+ continues to use gdkkeysyms-compat.h, which is
the gtkimcontextsimple.c, since porting that requires porting more
custom Perl code.
Since we have a new mechanism for requesting sizes: GtkSizeRequestIface;
it makes no sense to maintain this cache on the GtkWidget structure...
removing the requisition cache however does not break the old "size-request"
signal which is there for backwards compatability reasons.
In any case widget->requisition should not have been accessed,
gtk_widget_get_child_requisition() would have been the correct way
to consult the cache.
This commit also deprecates the newly added gtk_widget_get_requisition()
API and makes it fallback on gtk_size_request_get_size().
The GtkSubmenuDirection and GtkSubmenuPlacement enumerations
have been deprecated as public API for a while, but are still used
internally in the menu code. Move them to a private header. This
also prevents to generation of GObject boilerplate for these enums.
Removed the old toplevel window size-request signal and
do the clamping in gtk_menu_get_height_for_width() instead,
also make sure to invalidate the size before doing a new
request just after invoking the delegate menu position func.
Now GtkMenu/GtkMenuItem request/allocate in height-for-width
manner... to reduce the height of the menu one must explicitly
set the requested minimum width of the menu to a greater value
(using gtk_widget_set_size_request()).
This completes the move to get rid of using a GdkRegion for the
navigation region and the only user of gdk_region_polygon(). We keep
track of the triangle and compute in/out points ourselves now.
Unfortunately the DRAW_STAYUP_TRIANGLES debugging code doesn't work
using cairo, so I removed it completely.
