As discussed on desktop-devel-list [1], "There should be an intuitive,
consistent, immediate way to jump to the widgets that live in the
header bar." F10 has been suggested for this as it is already used to
active menubars.
F10 will focus the custom titlebar widget if the window has one and it
isn't already focused. If the titlebar widget doesn't exist or is
already focused then F10 focuses the menubar if there is one.
[1] https://mail.gnome.org/archives/desktop-devel-list/2014-February/msg00176.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=725141
gnome-terminal is still using this setting, so we'll let
applications override it for another cycle. It is no longer
backed by a system-wide setting, though, and it will still
go away eventually.
This partically reverts b26c74e5da
Make the main (and only) entry-point to gtkmodelmenu.c the now-public
gtk_menu_shell_bind_model().
Move the convenience constructors (gtk_menu_new_from_model() and
gtk_menu_bar_new_from_model()) to their proper files.
Remove the private header file.
Simplify the code a bit by making the initial populate part of the
bind() call.
https://bugzilla.gnome.org/show_bug.cgi?id=682831
In gtk_menu_bar_draw, the check for shadow type != none
disables rendering of the background instead of the frame.
The check should be moved down to gtk_render_frame.
Patch by Peter de Ridder,
http://bugzilla.gnome.org/show_bug.cgi?id=670390
And the getter, too: gtk_menu_item_get_right_justified() and the
corresponding property. Also make the only caller use the private
structure (as it did before the recent patches).
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".
