These AtkRelation types are added automatically for widgets with a label
specified (e.g. via gtk_label_set_mnemonic_widget, gtk_frame_set_label,
and gtk_frame_set_label_widget). When such specification is absent, the
accessible relationship must be manually set.
https://bugzilla.gnome.org/show_bug.cgi?id=726996
Commit faba7df4fe changed the logic in
apply_emblems() so that GtkIconInfo->emblems_applied would be set to
TRUE even in case there was no emblem info available, which confuses the
theme cache.
This commit changes the logic back, so that NULL is returned from
apply_emblems_to_pixbuf() when there are no emblems available, fixing
the bug.
https://bugzilla.gnome.org/show_bug.cgi?id=726830
The compositing that is meant here is really specific to the
X11 Composite extension, and does not apply to Wayland.
This is very rarely used functionality anyway, and none of
the other backends support it.
This way, we don't create lots of cell accessibles when creating the
first one (because surely one is the parent/child of another who again
is a parent/child of another who again....)
Nobody was reffing those related object in the first place and that
was causing random crashes.
And if somebody had reffed those related objects, they'd have caused
reference cycles.
https://bugzilla.gnome.org/show_bug.cgi?id=726838
This fixes an issue where the theme-provided border-width prevents
dialog contents from lining up properly with the headerbar. To make
this work in message dialogs, we have to explicitly set the border-
width of the action area to 0.
In select-folder mode, we are putting the directory name into the
entry ourselves. Then the entry appends a /. If we react to this
'spontaneous' change of the entry by clearing the list selection,
this will in turn make us clear the entry. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=726855
Setting windows undecorated was broken by some of the recent
shadow width changes. We need to ensure that shadow width is
zero for undecorated windows, then things work again.
If the delete event ends up destroying the widget, unsetting
priv->delete_event_handler will happen on invalid memory, so
unset it before the widget is possibly destroyed.
https://bugzilla.gnome.org/show_bug.cgi?id=726825
Theoretically, we apply the shape mask client-side ourselves
with an ARGB32 pixmap and intersect it to get a union shape,
but I don't particularly care enough to write that code.
Realistic application code using bounding shapes in 2014 is
quite rare.
Widgets should only call set_realized() after having created and
registered their GDK windows. In this case, the creation of the style
context (or more exactly: figuring out the scale factor for it) requires
knowing if the widget is already realized. Which it isn't.
https://bugzilla.gnome.org/show_bug.cgi?id=726717
