nitems is never guaranteed to be defined in sys/params.h as it is meant
to be defined within a protected ifdef __KERNEL conditional.
Use G_N_ELEMENTS from GLib which is the proper way of doing this.
In gtk_entry_get_icon_pixbuf() we unreference the pixbuf that
_gtk_icon_helper_ensure_pixbuf() gives us back, since the function
doesn't return a reference, and by doing so we're able to return the
reference owned by the cached icon helper.
Since the icon helper method can return NULL though, if no icon
properties have been set on it, guard for != NULL before unreffing the
pixbuf, as that would cause a critical warning.
https://bugzilla.gnome.org/show_bug.cgi?id=679537
Right now, when we create a GtkModelMenu for a GMenuModel, we listen to
changes to the menu's attach-widget to detect when a toplevel
GtkApplicationWindow becomes available to fetch actions from it.
This unfortunately breaks this simple code:
GtkWidget *application_window = gtk_application_window_new();
GtkWidget *menu_button = gtk_menu_button_new();
GMenuModel *menu_model = get_menu_model();
gtk_menu_button_set_menu_model(menu_button, menu_model);
gtk_container_add(GTK_CONTAINER(application_window), menu_button);
Since GtkMenuButton creates a GtkModelMenu and sets itself as its attach
widget before it's added to a hierarchy containing a
GtkApplicationWindow.
Fix the bug by simply listening for changes in the window hierarchy, and
creating the menu model when the attach widget is added to an
application window.
https://bugzilla.gnome.org/show_bug.cgi?id=679454
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 is fallout from commit 257b42e2f9 -
those fields were already getting freed in
gtk_application_shutdown_x11() and my commit caused crashes on quit
instead.
Thanks to Rico Tzschichholz for reporting the bug and testing this fix.
As an addition to 1042372670, themes might
want to avoid using the hardcoded GTK defaults for legacy GtkStyle
values. Add a gtkstyle-fallback style class that can be used by themes
to tweak the legacy GtkStyle defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=679092
Since we explictly call popup_menu with NULL when it's
keyboard-activated, we need to be careful and not access event->device
without checking for event != NULL before.
The signals for the action group were being disconnected when the action
group was explicitly removed from the GActionMuxer but the same was not
being done when it was finalized.
This means that a change in the state of an action group that used to be
associated with a finalized GActionMuxer would result in a crash. This
would happen for stateful application actions after closing a window.
We can't expose colors with alpha in the GtkStyle colors, since
GdkColor has no alpha. Currently we throw away alpha completely,
which fails very badly for completely transparent backgrounds,
which now is the default for most widgets, as it typically
end up with black-on-black.
We handle this by falling back on the default/previous colors for
transparent colors. This is is simple and avoids complete failure.
https://bugzilla.gnome.org/show_bug.cgi?id=671437
Don't use ASCII control characters to denote the input of Esc, Tab,
Return/Enter, Backspace and Delete, as it seems that it is not how
Windows handle them, and they cause weird characters to appear in the
input field on GTK+3 programs in non-English Windows. Instead, let
these keys be handled as-is on Windows, like what is done in GTK+-2.x.
Checked with mclasen on IRC, and thanks to the people who verified the
patch to not break anything on English Windows.
When using Shift-Tab to move the focus out of page content onto
the tab label, we end up in a situation where both Tab and Shift-Tab
move focus back into the page, which is not really what is expected
when the notebook is part of a dialog.
Instead, arrange things so that using Shift-Tab with focus on a
tab label moves the focus out of the notebook.
http://bugzilla.gnome.org/show_bug.cgi?id=669986
It turns out that we can end up removing a notebook child while
the tab is still 'detached'. Child removal causes
gtk_notebook_remove_tab_label() to be called on the tab label,
but that function did not deal with the eventuality that the tab
label may be a child of the dnd window.
http://bugzilla.gnome.org/show_bug.cgi?id=677943
