Deal with GtkWidget::drag-data-get in an asynchronous manner
I've a problem with the GtkWidget::drag-data-get signal, that it's meant to return the data immediately, which is quite suboptimal for data being stored remotely. As in evolution#440 , the user drags a mail folder to a Nautilus folder, which means, once the drop is "confirmed", the application asks for each message in the folder and constructs either an mbox file or a pdf file of them. Not all messages are available locally for remote accounts, thus they should be downloaded, thus doing network I/O, which can take from seconds to minutes or more, depending on the folder size and the respective message size and the responsiveness of the server and the network bandwidth usage and so on. The problem is that the application freezes during this time, which can lead to the "Not responding, kill or wait" question from the desktop environment, which is quite bad.
That being said, is there a way to deal with the GtkWidget::drag-data-get signal in an asynchronous way, to have the application alive and allow the user to cancel the ongoing message download, if needed?
The only workaround I've been thinking of was to run a mainloop in the signal handler and wait for the finish, but that has many caveats, one of them being multiple drag&drop requests being handled on the stack at the same time, possibly cancelling the first run before the second is finished (or cancelled). Not talking that running the main loop int he signal handler could cause some other issues.
I didn't find anything legitimate for this in the documentation, the drag&drop in gtk+ seems heavily synchronous operation. Note that I cannot download the message as soon as the drag begins, both because I do not know whether the data will be needed at all and because it can take minutes anyway, while the user will finish the drag long before the messages are downloaded.