After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 710546 - Improve XDS dnd support in file-roller
Improve XDS dnd support in file-roller
Status: RESOLVED FIXED
Product: file-roller
Classification: Applications
Component: general
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: Paolo Bacchilega
file-roller-maint
Depends on:
Blocks:
 
 
Reported: 2013-10-20 13:52 UTC by Nelson Benitez
Modified: 2013-10-27 12:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't use a fake name when communicating the XDS dragged file name (1.93 KB, patch)
2013-10-20 13:56 UTC, Nelson Benitez
none Details | Review
fix crash on _fr_window_ask_overwrite_dialog() function (1.48 KB, patch)
2013-10-20 13:57 UTC, Nelson Benitez
none Details | Review
Improve XDS dnd support (5.90 KB, patch)
2013-10-20 14:04 UTC, Nelson Benitez
none Details | Review
Screencast showing patches result of file-roller dropping files to gedit (1.40 MB, video/webm)
2013-10-20 14:32 UTC, Nelson Benitez
  Details

Description Nelson Benitez 2013-10-20 13:52:17 UTC
Hi,
I'm about to attach two patches for improving XDS dnd support in file-roller, and another patch for a crash I found when testing dnd.
Comment 1 Nelson Benitez 2013-10-20 13:56:54 UTC
Created attachment 257755 [details] [review]
Don't use a fake name when communicating the XDS dragged file name

    dnd: don't use a fake name when communicating the xds dragged file
    
    Use the real name, as the target application may need it (eg.
    nautilus for revealing it, or gedit to open it).
Comment 2 Nelson Benitez 2013-10-20 13:57:49 UTC
Created attachment 257756 [details] [review]
fix crash on _fr_window_ask_overwrite_dialog() function

    fr-window: fix crash on _fr_window_ask_overwrite_dialog() function
    
    Don't immediatly unref 'destination' after passing it to
    g_file_query_info_async() , instead unref it from within the callback
    for the aforementioned function when it's done with it.
Comment 3 Nelson Benitez 2013-10-20 14:04:29 UTC
Created attachment 257757 [details] [review]
Improve XDS dnd support

    fr-window: Improve XDS dnd support
    
    Improve file-roller XDS dnd support by sending the 'success'
    response only after the file(s) has already been extracted, so
    the target dnd application can operate on it (eg. gedit may
    want to open it, nautilus may want to reveal it).
    
    The XDS spec states that when sending the success ('S') response, the
    file should have already been written to disk, but assumed this would
    be done in a synchronous (and thus blocking) operation, asynchronous
    (callback based) apis were not common when the XDS spec was done so
    that's probably the reason.
    
    So as file-roller does, in a right manner, its file operations 
    asynchronously, thats probably why it didn't care to send the success 
    response at the right time.
    
    This patch workarounds the XDS spec limitation and makes file-roller to wait
    for the async operations to complete before sending the success response.
    
    It does so, without blocking the main ui thread, by creating and using a
    GMainLoop the same way as it's done by the gtk_dialog_run() call, which
    shows a dialog and waits for its response without blocking the ui.
Comment 4 Nelson Benitez 2013-10-20 14:32:03 UTC
Created attachment 257760 [details]
Screencast showing patches result of file-roller dropping files to gedit

This is a screencast showing the patches behaviour, where I drag some files from file-roller and drop it on gedit and gedit opens them, things to note:

- I dragged the same file twice just to show how gedit handles that, because every time we offer a XDS file, gedit gives as destination directory a tmp directory created with random name everytime.

- I also dragged a file which is password protected, just to show how file-roller ui does not block and we are able to enter our password while gedit waits for the xds success response which happens after we enter our password and the file is finally extracted.



Note: Take in mind if you try to drag and drop several files onto gedit only the first one will be opened, this is due to limitation of XDS spec, which does not have support for transfers of more than one file.
Comment 5 Nelson Benitez 2013-10-20 15:21:58 UTC
I forgot to add, that for gedit to work as in the screencast you need the patch in bug 430798 comment 6
Comment 6 Paolo Bacchilega 2013-10-27 12:34:35 UTC
Hi Nelson,

I've pushed your patches to master now.  I've then fixed drag&drop from the 
folder tree, and added some other points where to reset dnd_extract_is_running.

Thank you for your work.