The data device manager is a global object that provides the support
infrastructure around data devices. These data device objects are the basis
for handling drag and drop as well as selections in Wayland.
As pointed out in bug 665999, these were just not right.
Before this commit, the nicks were 'output' and 'only'.
After this commit, they are 'input-output' and 'input-only'.
This means we don't have to have hardcoded "/usr/share/wayland" to find the
cursors.
This change also fixes up the warning messages for when loading fails.
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.
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>
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.
This turns GdkWin32DragContext into a proper GdkDragContext subclass.
Because we now correctly initialize GdkWin32DragContext in
gdk_drag_context_new, we no longer crash immediatly when a DnD
operation is initialized (the find_window, drag_status, ... vfuncs
where all pointing to 0x0 instead of their proper win32 implementations).
We now try to consistently refer to GdkDragContext as "context",
GdkWin32DragContext as "win32_context" and the ole2 related
target_drag_context and source_drag_context as "ctx".
Members of GdkWin32DragContext only used by the ole2 DnD codepaths
are now explicitly marked with a ole2_dnd_ prefix.
gdk_cairo_region_create_from_surface doesn't work correctly on PPC.
This is most prominently seen with the GTK window resize grip, the
shape of which is mirrored every eight pixels horizontally.
At the same time, use an A1 surface for the resize grip shape to
eliminates an A8->A1 surface conversion.
Add GDK_MODIFIER_INTENT_SHIFT_GROUP to enum GdkModifierIntent
and handle it in gdk_keymap_get_modifier_mask(). Add an X11
impl of the method and return keymap_x11->group_switch_mask.
Return 0 from the default impl because we don't know.
If the keyboard group shifting modifier is *also* a normal
accelerator modifier, we need to special case it when calling
gdk_keymap_translate_keyboard_state(), so we get the right
key symbol for accelerators (for example we want Option-O,
not Option-Ø displayed in menu items). This patch should only
affect quartz where the Alt key both shifts the group and can
be used as accel modifier, and not X11 or Win32 where AltGr
is not used for accelerators.
- fix quartz' gdk_keymap_translate_keyboard_state() to return
the right consumed_modifiers
- add _gtk_translate_keyboard_accel_state() which does the
special casing
- use it everywhere instead of gdk_keymap_translate_keyboard_state()
g_checksum_get_digest checks to ensure that the passed digest_len is long
enough to hold the digest, before setting it to the actual length of the
digest returned. Digest_len is uninitialized in the code, so if you're
lucky it will be larger than 20 and everything will work fine. If you're
unlucky, g_checksum_get_digest will return either -1 or some number less
than 20, and the g_assert(digest_len==20) will fail.
Wake up the run loop unconditionally (don't check if it is waiting) because
it might go into waiting state right after we checked for it. Fixes GIMP
startup (which has a lot of GIOChannel I/O but zero NSEvents) from several
minutes to a few seconds.
(cherry picked from commit 0729cdc9a1)
We now do proper handling of existing invalid regions, and
we use ScrollDC which allows us to specify the right clip
region rather than just the bounding rect.
