This replaces the wl_input_device with wl_pointer, wl_keyboard, wl_touch all
tied together under a wl_seat.
This is quite a radical change in protocol and for now keyboard handling is
disabled.
This requires the SHM object be initialised - therefore this is the most
logical (if slightly ugly place.)
We also need to make sure that we do something clever to load the correct
cursor theme.
Both GtkListStore and GtkTreeStore had a few methods that allowed
-1 to mean 'append' when specified as a position, but others that
demanded positive position arguments. Make this consistent by
always allowing -1.
https://bugzilla.gnome.org/show_bug.cgi?id=667808
The recently-used.xbel storage for recently used files is located inside
the $XDG_DATA_HOME directory; there's no actual guarantee that the
directory has been created already, even though it's very highly
probable on any modern distribution. We should create it, along with its
intermediate parents, before constructing the file monitor that we use
to get change notifications.
https://bugzilla.gnome.org/show_bug.cgi?id=671817https://bugzilla.gnome.org/show_bug.cgi?id=667808
The builder XML description has an action for "win.parse" but the
application is looking for "win.paste". Rename the label to
"_Paste" and the action to "win.paste" in the window action XML.
https://bugzilla.gnome.org/show_bug.cgi?id=678829
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
