Bug 188857

Additionally, the destination folder is opened when dragging and dropping a 
file into, for example, Dolphin.

Confirm on kde 4.3.4

*** Bug 254528 has been marked as a duplicate of this bug. ***

Changing the default assignee in the currently open Ark bug reports to me.

*** Bug 259825 has been marked as a duplicate of this bug. ***

Changing the report title to make it more descriptive.

*** Bug 267252 has been marked as a duplicate of this bug. ***

*** Bug 273332 has been marked as a duplicate of this bug. ***

I'm changing the bug title from "Ark opens the destination folder even when the extraction is cancelled in the file overwrite dialog and after drag'n'drops" to "Ark follows settings in the Extraction dialog even when it was not used" to better reflect what is really happening.

It turns out that those settings are used every time an extract was performed, even if not successful and even if it was via drag'n'drop -- as bug 273332 shows, this is more annoying than I had previously thought, as the "close Ark after extraction" behaviour will be followed even after a single drag'n'drop. Due to this, I'm also raising the bug priority a little.

(In reply to comment #1)
> Additionally, the destination folder is opened when dragging and dropping a 
> file into, for example, Dolphin.

If it would do that, that'd be probably even useful, but what Ark does: it just opens the user's homedir - no matter where the files have been dragged to.

(In reply to comment #10)
> (In reply to comment #1)
> > Additionally, the destination folder is opened when dragging and dropping a 
> > file into, for example, Dolphin.
> 
> If it would do that, that'd be probably even useful

How so? If you are dragging and dropping from Ark to a directory in Dolphin, why should Ark open another Dolphin window showing the same directory?

> but what Ark does: it just opens the user's homedir - no matter where the files have been dragged to.

I could not reproduce this here -- I opened a .tar.gz archive in Ark, dragged one file from it to /tmp in Dolphin and it was indeed extracted into /tmp.

(In reply to comment #11)
> (In reply to comment #10)
> > but what Ark does: it just opens the user's homedir - no matter where the files have been dragged to.
> 
> I could not reproduce this here -- I opened a .tar.gz archive in Ark, dragged
> one file from it to /tmp in Dolphin and it was indeed extracted into /tmp.

It is indeed, but a new window is still opened with ~. I think you might've misread comment #10.

Oops, sorry :) Indeed, I was able to reproduce it now.

SVN commit 1242112 by rkcosta:

Move destination directory retrieval to ExtractJob.

Part::m_destinationDirectory was only set when the files were
extracted using the extraction dialog.

This meant that if the user had chosen to open the destination
directory after an extraction he would always have his home directory
open when the extraction was done via quick extract or drag'n'drop, as
KRun::runUrl would have an empty KUrl as its parameter.

We now make the destination directory passed to ExtractJob publicly
available, and retrieve it from there.

BUG: 188857
FIXED-IN: 4.7.0

 M  +5 -0      kerfuffle/jobs.cpp  
 M  +2 -0      kerfuffle/jobs.h  
 M  +8 -6      part/part.cpp  
 M  +0 -1      part/part.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1242112

SVN commit 1242113 by rkcosta:

Specify when the extraction dialog's settings should be followed.

On ExtractJob's side, we make the extraction options it received
publicly accessible.

On Part's side, we set a "FollowExtractionDialogSettings" option to
true only when the extraction dialog was used to extract files, and
only actually follow these settings (for now, open the destination
directory and/or quit Ark after the extraction) when that option is
set.

BUG: 188857
FIXED-IN: 4.7.0

 M  +5 -0      kerfuffle/jobs.cpp  
 M  +1 -0      kerfuffle/jobs.h  
 M  +10 -1     part/part.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1242113

SVN commit 1242114 by rkcosta:

Move destination directory retrieval to ExtractJob.

Part::m_destinationDirectory was only set when the files were
extracted using the extraction dialog.

This meant that if the user had chosen to open the destination
directory after an extraction he would always have his home directory
open when the extraction was done via quick extract or drag'n'drop, as
KRun::runUrl would have an empty KUrl as its parameter.

We now make the destination directory passed to ExtractJob publicly
available, and retrieve it from there.

Forwardport of r1242112.

CCBUG: 188857

 M  +5 -0      kerfuffle/jobs.cpp  
 M  +2 -0      kerfuffle/jobs.h  
 M  +8 -6      part/part.cpp  
 M  +0 -1      part/part.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1242114

SVN commit 1242115 by rkcosta:

Specify when the extraction dialog's settings should be followed.

On ExtractJob's side, we make the extraction options it received
publicly accessible.

On Part's side, we set a "FollowExtractionDialogSettings" option to
true only when the extraction dialog was used to extract files, and
only actually follow these settings (for now, open the destination
directory and/or quit Ark after the extraction) when that option is
set.

Forwardport of r1242113.

CCBUG: 188857

 M  +5 -0      kerfuffle/jobs.cpp  
 M  +1 -0      kerfuffle/jobs.h  
 M  +10 -1     part/part.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1242115

OK, so pretty much everything has been fixed.

The only remaining issue is that of the extraction dialog's settings being followed if a user cancelled the extraction or if there was an error. I've decided to close the bug anyway because this is a separate issue that affects other parts of the code as well (the infrastructure for making it work as expected in this part of the code is already there).

*** Bug 283460 has been marked as a duplicate of this bug. ***