Created attachment 327401 [details] [review]
pasteManager: Turn drop target support into a GObject interface

The paste manager has some old support for turning widgets into
drop targets for supported types and upload dropped data to the
appropriate paste service. While sometimes useful, without any
confirmation we ended up with accidental uploads more often than
not and disabled it.
With the re-enabled paste support from last cycle we now have a
confirmation UI that we can leverage for processing drops as
well - however this requires separating drop handling from doing
the actual upload, and a singleton like PasteManager is fairly
ill-suited to connect the widget receiving the drop with the one
asking for confirmation.
So instead, turn drop target support into an interface that objects
can implement to have appropriate signals emitted for each drop on
any widget set up as drop destination via addTargets().

Created attachment 327402 [details] [review]
entryArea: Make paste handlers public

Those are currently used to handle content pasted in the entry, but
we will soon re-use them for dropped content as well.

Created attachment 327403 [details] [review]
chatView: Re-enable drop target support

Drag-n-drop provides an alternative to the clipboard for sharing content
between applications, however our support has been disabled since commit
ea4c7f61840. As we now have everything in place to hook up drops with the
existing paste/upload UI for confirmation, we can finally make the chat
log a drop target again.

Created attachment 327404 [details] [review]
pasteManager: Use connect_after() to receive drag data

GTK+'s text widgets already have built-in DND support which may conflict
with our own drop target support. Currently that is not an issue, as the
chat log is not editable, which disables the built-in support. However we
want to extend the entry's built-in drop target support as well, where
this will be an issue - in particular as it should use either the regular
or our custom support.
Running our custom GtkWidget::drag-data-received handler after the object
method handler will allow classes to do that by either making the built-in
handler a NOOP or stopping the signal emission.

Created attachment 327405 [details] [review]
entryArea: Extend drop target support

GtkEntries are drop targets, but the built-in behavior does not match
how we handle clipboard pastes:

 - only text content is supported
 - drop text is always inserted into the entry,
   independent from the number of lines

Make DND and clipboard handling consistent by only using the built-in
support for text drops that don't exceed the line limit we apply to
clipboard pastes, and use our own drop target support otherwise.

Attachment 327401 [details] pushed as 29c1d1a - pasteManager: Turn drop target support into a GObject interface
Attachment 327402 [details] pushed as afba5fa - entryArea: Make paste handlers public
Attachment 327403 [details] pushed as 992749a - chatView: Re-enable drop target support
Attachment 327404 [details] pushed as 14376a2 - pasteManager: Use connect_after() to receive drag data
Attachment 327405 [details] pushed as e442fce - entryArea: Extend drop target support