When the window has no mnemonics modifier set, as in the case of a
GtkMenu, never schedule a display of mnemonics on focus-in.
Previously, for those windows, the GdkModifierType mask fetched from the
device would typically have been zero, leading to the
mnemonic_modifier == (mask & gtk_accelerator_get_default_mod_mask ())
check to succeed, so we would always trigger a display for popup menus.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
Don't mention "auto mnemonics", since those methods are purely about
scheduling a delayed display, and that makes understanding the code a
bit harder.
https://bugzilla.gnome.org/show_bug.cgi?id=697144
This way we don't have to reopen all the time for pure updates,
and we can immediately unlink the shm file to avoid "leaking" them
on improper shutdown.
We now only update surface data after we have painted. Before we painted
in an idle, which meant we might send black data some times if we e.g.
resized the window and had not painted yet. Also, it means we're updating
less often to the daemon, saving resources.
We still have to queue a flush in the idle for non-draw operations,
otherwise e.g. resize of a toplevel will never be flushed if the clock
is frozen (e.g. during toplevel resize).
We don't want to update the window size on configure event, only
the position, as the size is client side controlled. We were
updating to an old size during resizes which causes us to send
surfaces of the wrong size to the daemon.
The following CSS would infloop:
@define-color self @self
as it would infinitely lookup the color named "self" and try to resolve
it. This patch adds detection of such cycles to the resolve function by
keeping a list of currently resolving colors in the cycle_list variable.
If a named color references a nonexistant named color, we didn't catch
that error and ended up crashing on a NULL-dereference.
This crashed Boxes, because its CSS referenced values from the theme
that didn't exist in any theme.
We were calling gtk_overlay_child_allocate() both in realize
and in add as we wanted to create and position the child windows
for the widgets. However, this call also actually called
gtk_widget_size_allocate() on the child, which it shouldn't. In some
cases the overlay is realized before being allocated, and thus it
will allocate the child at 0x0 which is an invalid size for it to be in.
In particular, if the child has margins set this will result in negative
allocations and warnings.
This fix splits out the allocation computation so that
gtk_overlay_create_child_window can use it without callers
having to call gtk_overlay_child_allocate() to move the windows.
https://bugzilla.gnome.org/show_bug.cgi?id=696623
If a window is overlapped by a layered (i.e. partially transparent)
window then that region will not disappear from the native window clip
region. This lets us handle compositing multiple layers of windows.
For native subwindows this doesn't really work. For them we apply the
clip region as a shape to the native window which lets us have client
side windows overlapping the native window. However, with the addition
of the layered stuff the "overlapped-by-alpha-csw" part got broken, as
this area is not removed from the clip region of the native window.
We fix this by also removing the layered area when applying the shape.
This means alpha and alpha backgrounds don't work over native windows,
but there is not much to do about that.
https://bugzilla.gnome.org/show_bug.cgi?id=696370
