Calling gdk_keymap_add_virtual_modifiers causes _all_ virtual
modifiers to be added, which causes problem when they are co-located
on the same real modifier (as Super and Hyper often are). Effectively,
this made it impossible to enter key combinations involving Super,
since they all turn into Super+Hyper.
Move code for child allocation into the child allocation function. Don't
keep it in the overlay allocation code.
See the next commit for why this is useful.
When an implicit paint is flushed during expose, e.g. because a
non-double buffered widget is painting, make sure to copy the existing
data from the window surface we rendered before flushing back to the
paint surface, instead of using an empty base.
Code was already handling that (and said so in the comment), but only
when no implicit paint was used at all, and not in the case when it's
flushed mid-expose.
We used to only set the override color or font if it was different
than the existing value. However, that means you can't change it to
an override that is the same as the default value for the property.
With this fixed you can e.g. override with a color of 0,0,0,0 which
you couldn't before.
Previously all the commands that acted on the shell took the surface that was
to be acted on as parameter. Now we retrieve an object from the shell that
represents its state for the surface. With that wl_shell_surface object we can
then call methods on that.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
When gtk_render_arrow() is called, always add an ARROW style class to
the GtkStyleContext before rendering, so themes can specify a different
color for it.
https://bugzilla.gnome.org/show_bug.cgi?id=665420
Just always render the pixbuf ourselves and set it on the GtkImage in
the X11 case.
Code for other backends was already rendering the pixbuf manually before
translating it into a native type, so this greatly simplifies the code.
https://bugzilla.gnome.org/show_bug.cgi?id=665409
Instead of painting the window background on the grip_window we now
only paint it on the GtkWindow->window, and we make the grip_window
have a transparent background.
We can't really make transparent window handle background optional
via css atm, because the handle color is actually based on the
background color, so if that is set to transparent we won't draw
anything.
gdk_window_get_update_area is supposed to get the area where things
need painting, and remove them from the update areas. However, if
some area is covered by other windows with an alpha background we
can't just expect whatever the app choses to render in the update
area as correct, so we don't actually remove these areas, meaning
they will get correctly rendered when we get to the expose handlers.
gdk_window_move_region doesn't move children, so we can't copy
transparent child window regions with copyarea, so we remove these
from the copy region.
We track the areas that have alpha coverage so that we can
avoid using these as sources when copying window contents.
We also don't remove such areas from the clipping regions so
that they are painted both by parent and child.
This cleans up the expose handling a bit by using the existing
clip regions, and it allows us later to use painters algorithm
to do transparent windows.
