GitLab

We should conform to a minimal set of reasons for the gtk side to emit
a better GtkDragResult than GTK_DRAG_RESULT_ERROR. This fixes the notebook
tab DnD feature, where we rely on GTK_DRAG_RESULT_NO_TARGET.

In the wayland side, unfortunately we can't honor either NO_TARGET nor
USER_CANCELLED, we don't know of the latter, so we could return false
positives on the former.

https://bugzilla.gnome.org/show_bug.cgi?id=761954

We have this information in the XDND protocol, so we don't have
to blindly assume that the drop succeeded.

This includes managing input events and source-side DND events,
as well as setting the appropriate cursor and emitting the signals
that are expected in this mode of operation.

Valgrind complains about jumps based on uninitialized values
otherwise.

Instead of creating an intermediate pixbuf, just render
the window surface onto the new surface. Doing things this
way lets us avoid the cairo_surface_mark_dirty() call in
gdk_pixbuf_get_from_window(), which is not generally safe
to call on 'random' surfaces - it asserts that the surface
has no mime data attached, and the X11 backend uses mime
data for damage tracking purposes...

We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.

We can use the pointer of the default seat instead.

Showing the drag cancel animation can be done in the X11
drag context implementation now that we hold the drag
window there, and have the start coordinates.

Since we can't control if and when the application destroys
the drag widget, we take a snapshot of the window contents
and display that during the animation. This should be good
enough for all practical purposes.

These will be used in later commits.

Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.

Subsequent commits will make use of the data in some backends.

This makes the drag behavior under X11 match what we had previously.

This makes gdk_wayland_drag_context_get_dnd_window
backend-independent API and adds an implementation
for X11.

If the filter didn't return GDK_EVENT_TRANSLATE, the event struct would be
left unused and leaked.

This replaces all occurrences of 'explicitely' with 'explicitly'. Only
code comments and gtk-doc statements are affected.

https://bugzilla.gnome.org/show_bug.cgi?id=722429

If you set GDK_SCALE=2 in the environment then all windows will be
scaled by 2. Its not an ideal solution as it doesn't handle
multi-monitors at different scales, and only affects gtk apps.
But it is a good starting points and will help a lot on HiDPI
laptops.

The implementation is not working and unused, since XDND is the
de-facto standard under X nowadays.

https://bugzilla.gnome.org/show_bug.cgi?id=695476

Related: https://bugzilla.gnome.org/show_bug.cgi?id=664646

When the X server does not support the shape extension (as some
vnc implementations seem to), our DND code was always seeing
an empty input shape, so drops always missed their target.

http://bugzilla.gnome.org/show_bug.cgi?id=620240

gdk_x11_window_lookup_window() calls are done by this function alreayd,
so no need to do them manually.

No need to run sophisticated functions to guess it.

By making window caches refcounted. This fixes problems with leaking
drag contexts, as experienced in
https://bugzilla.gnome.org/show_bug.cgi?id=637691
and
https://bugzilla.gnome.org/show_bug.cgi?id=144324

Based on a patch by drago01@gmail.com

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>

Also rename all the macros etc.

These functions were essentially just calling setlocale anyway.
The X11 version was also setting a gdk_use_mb variable that
is not used anywhere.

Moving the direct-access redefinitions of various macros
to gdkprivate-x11.h and use that header throughout in x11/.

Also remove a workaround for a long-fixed X server bug.

The X11 backend exports a number of symbols which are _-prefixed
(so don't become part of the gdk api), but are not named in a
way to prevent accidental clashes between backends.

The one API change here is that the gdk_xid_table functions
have been removed - they did not server an purpose, since the
xid table only stores windows anyway, and we already have a
lookup-by-xid function for windows.