Version: svn r948150 (using Devel) OS: Linux Installed from: Compiled sources Currently, if a file is extracted and the "Open destination after extraction" option was selected, the destination is opened even when the user pressed the Cancel button when prompted by a file overwrite dialog. To reproduce, just extract a file somewhere and then try to extract it again with the mentioned option selected -- the file overwrite dialog will show up, and even if you click Cancel the destination will be opened.
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. ***