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.
