This is an expected keybinding, and it is not hard to support.
Note that we use a private ::escape signal instead of using
::cancel directly, since we want to be able to suppress the
cancellation when we are on a progress page.
https://bugzilla.gnome.org/show_bug.cgi?id=579625
When closing the application window before closing the inspector window,
the selected widget will be set to NULL once and all the property pages
will try to g_object_weak_unref that NULL widget, so bail out in
gtk_inspector_prop_list_set_object if it's NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=736201
When GtkApplicationWindow has a menubar, we don't chain up
to the GtkWindow size_allocate, which used to position the
popovers. Move that to _gtk_window_set_allocation() which
is always called by GtkApplicationWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=736205
... just because there is no style context instantiated yet. Instead,
instantiate a style context during realize() and ask it.
Fixes problems with dim labels not being dimmed on first show.
Testcase included.
https://bugzilla.gnome.org/show_bug.cgi?id=735240
Just pretend that the main widget is an empty widget the size of the
overlay.
Makes it possible to write testcases where no size requests are run on
overlay widgets before size_allocate() is called.
Testcase included.
(gnome-shell-extension-prefs:22382): GLib-GObject-WARNING **: invalid cast from 'GtkInvisible' to 'GtkWindow'
(gnome-shell-extension-prefs:22382): Gtk-CRITICAL **: gtk_window_set_transient_for: assertion 'parent == NULL || GTK_IS_WINDOW (parent)' failed
#1 0x00007fffeeb81a12 in g_log (log_domain=log_domain@entry=0x7fffeeea3464 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7fffeeeaa878 "invalid cast from '%s' to '%s'") at gmessages.c:1079
#2 0x00007fffeee9c2a9 in g_type_check_instance_cast (type_instance=0xb314c0, iface_type=iface_type@entry=9020048) at gtype.c:4021
#3 0x00007ffff0a06e25 in gtk_tooltip_set_last_window (tooltip=tooltip@entry=0xbb8c10, window=<optimized out>) at gtktooltip.c:910
#4 0x00007ffff0a08dfd in _gtk_tooltip_handle_event (event=event@entry=0xbf72c0) at gtktooltip.c:1538
#5 0x00007ffff090d7a9 in gtk_main_do_event (event=0xbf72c0) at gtkmain.c:1785
#6 0x00007ffff0496ab2 in gdk_event_source_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>) at gdkeventsource.c:364
#7 0x00007fffeeb7a8c3 in g_main_dispatch (context=0x807300) at gmain.c:3067
https://bugzilla.gnome.org/show_bug.cgi?id=736131
The list of devices was being scanned over incorrectly, causing us to
never actually fetch the keymap from the keyboard, as the keyboard was
the second device in the list, not the first.
This causes us to create a new temporary keymap every time, which is
quite expensive, because it involves parsing the entire XKB
file. Scanning the list correctly will cause us to use the XKB rules
file that was passed to us.
