When doing fallback for symbolic icons, we first shorten
the name at dashes while preserving the -symbolic suffix.
But after exhausting that, we should also try stripping
the suffix.
https://bugzilla.gnome.org/show_bug.cgi?id=708163
When showing a tooltip on the edge of a monitor, the tooltip could be wrongly
placed and be shown going from one monitor to the next.
This happened because the current_window wasn't set visible, and when it wasn't
the returned allocated size would be 1, hence wrong calculations.
Signed-off-by: Olivier Brunel <jjk@jjacky.com>
https://bugzilla.gnome.org/show_bug.cgi?id=698730
Some symbols in the generated Wayland code were getting
decorated with WL_EXPORT, causing them to show up in the
libgdk exports. We don't want that.
https://bugzilla.gnome.org/show_bug.cgi?id=710141
We may get a NULL region passed to the backend, which means
'nothing is opaque'. In that case, don't crash, but pass
the information on to the compositor.
http://bugzilla.gnome.org/show_bug.cgi?id=709854
With the stock system being deprecated now, we should provide
meaningful accessible names for buttons that are constructed
from icon names or GIcons. This commit reuses the existing
translations.
It is possible that some common icon names are not covered
here because they were not present as stock items. These can
be added to the table later.
Discovered via a crash because b's (dest's) toplevel was NULL;
ensuring that the dest is actually a GdkWindow or setting b to NULL
prevents that path from being taken.
This test demonstrates that various deprecated ways
to construct buttons and menuitems still work as they
are supposed to, including always-show-image functionality.
Previously, the "Places" sidebar was populated by the update_places()
call from within gtk_places_sidebar_style_set(). After
742a2f11a9, update_places() is never called
and the sidebar is never populated unless gtk_places_sidebar_add_shortcut()
happens to be called. This commit fixes this by calling update_places()
at the end of gtk_places_sidebar_init().
https://bugzilla.gnome.org/show_bug.cgi?id=709522
The size of the shadow and invisible borders can (and usually
will) change between backdrop and focused windows, while the
overall window size remains unchanged. This causes the visible
window to visually 'jump'. We can avoid this by always reserving
the maximum of the focused and unfocused border sizes. The code
for positioning the input-only windows making up the invisible
border is adjusted to deal with this. We now always place the
invisible border right outside the visible content, even if the
shadow extends out much farther.
https://bugzilla.gnome.org/show_bug.cgi?id=707524
