Do not lie to W32 about the formats that we provide or accept.
Originally the logic behind such lies was that GdkPixbuf allows us to
convert any supported image to BMP or PNG, and therefore we should
announce that we always provide/accept BMP and PNG along with other
formats.
But that's not how it works. GDK has built-in serializers and
deserializers for all pixbuf formats (where it just invokes GdkPixbuf
API) and will use them automatically to read or write GdkTexture
objects (internally wrapping GdkPixbuf objects where necessary). The
encoding and decoding of images is handled
by GdkContent(De)Serializers, backend has nothing to do with it.
Therefore W32 GDK backend should only offer formats that it can
actually do conversion for by itself (such as image/bmp <-> CF_DIB,
or text/uri-list <-> CFSTR_SHELLIDLIST).
* Remove clipdrop->dnd_target_state, it's not used anymore
* Remove non-functioning _gdk_dropfiles_store(), store dropfiles
list in GdkWin32Drop instead
* Fix multiple comment typos
* Fix _gdk_win32_get_clipboard_format_name_as_interned_mimetype() to
leave names that look like mime/types alone
* Refactor _gdk_win32_add_w32format_to_pairs() to populate
GdkContentFormatsBuilder directly, instead of making a GList
* Rename context -> drag (still using GdkDragContext type,
but [almost?] all variables and comments say "drag" now)
* Rename GdkDropContext -> GdkDrop
* Rename some parameter names for clarity
* Rewrite local protocol to look more like OLE2 protocol
instead of mirroring the structure of the X11 API.
* Add handle_events field to GdkWin32DragContext,
to shut off event handling (temporary fix until GTK is patched up)
* Remove _gdk_win32_drag_context_find() - the drag object is stored
in GdkDrop instead. Use _gdk_win32_find_drag_for_dest_surface()
to get it initially.
* Remove target_ctx_for_window, droptarget context is stored
in the surface instead.
* Call gdk_drag_context_set_cursor() just like wayland backend does
(slightly broken for now)
* Clean up the action choosing code (filter source actions by using
keyboard state, pass that to GTK, get all actions supported by GTK in
response, match them up with filtered source actions, return the
result, falling back to COPY in case of multiple actions)
* Check drag_win32->protocol instead of the use_ole2_dnd variable where
possible
* Remove protocol checks from functions that are only used by the local
protocol
* Use event state to manufacture the keyboard state for WM_MOUSEMOVE
* Change function names printed by GDK_NOTE to name the actual
functions, not their theoretical generic GDK stack ancestors
* Consistently use drag_win32 and drop_win32 variables instead of a mix
of that and win32_drag/win32_drop
* Return FALSE from button handler to ensure that GTK gets the button
event to break implicit grab
* Emit leave event on failed idroptarget_drop() calls
Rename GdkWin32Selection to GdkWin32Clipdrop, since GdkSelection
is mostly gone, and the word "selection" does not reflect the
functionality of this object too well.
Clipboard is now handled by a separate thread, most of the code for
it now lives in gdkclipdrop-win32.c, gdkclipboard-win32.c just uses
clipdrop as a backend.
The DnD source part is also put into a thread.
The DnD target part does not spin the main loop, it just
emits a GDK event and returns a default value if it doesn't get a reply
by the time the event is processed.
Both clipboard and DnD use a new GOutputStream subclass to get data
from GTK and put it into a HGLOBAL.
GdkWin32DragContext is split into GdkWin32DragContext and GdkWin32DropContext,
anticipating a similar change that slated to happen to GdkDragContext.
OLE2 DnD protocol is now used by default, set GDK_WIN32_OLE2_DND envvar to 0
to make GDK use the old LOCAL and DROPFILES protocols.
https://bugzilla.gnome.org/show_bug.cgi?id=773299
