Bug 188857 - Ark follows settings in the Extraction dialog even when it was not used
Summary: Ark follows settings in the Extraction dialog even when it was not used
Status: RESOLVED FIXED
Alias: None
Product: ark
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: HI normal with 20 votes (vote)
Target Milestone: ---
Assignee: Raphael Kubo da Costa
URL:
Keywords: junior-jobs
: 254528 259825 267252 273332 283460 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-04-05 07:29 UTC by Raphael Kubo da Costa
Modified: 2012-04-16 14:49 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.7.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raphael Kubo da Costa 2009-04-05 07:29:35 UTC
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.
Comment 1 Raphael Kubo da Costa 2009-04-30 04:00:50 UTC
Additionally, the destination folder is opened when dragging and dropping a 
file into, for example, Dolphin.
Comment 2 Kamil Neczaj 2009-12-10 10:32:05 UTC
Confirm on kde 4.3.4
Comment 3 Raphael Kubo da Costa 2010-10-18 23:13:23 UTC
*** Bug 254528 has been marked as a duplicate of this bug. ***
Comment 4 Raphael Kubo da Costa 2010-12-08 02:18:51 UTC
Changing the default assignee in the currently open Ark bug reports to me.
Comment 5 Raphael Kubo da Costa 2010-12-15 04:46:08 UTC
*** Bug 259825 has been marked as a duplicate of this bug. ***
Comment 6 Raphael Kubo da Costa 2011-02-27 16:54:41 UTC
Changing the report title to make it more descriptive.
Comment 7 Raphael Kubo da Costa 2011-02-27 16:55:28 UTC
*** Bug 267252 has been marked as a duplicate of this bug. ***
Comment 8 Raphael Kubo da Costa 2011-05-15 16:32:08 UTC
*** Bug 273332 has been marked as a duplicate of this bug. ***
Comment 9 Raphael Kubo da Costa 2011-05-15 16:35:16 UTC
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.
Comment 10 Elias Probst 2011-05-16 15:31:11 UTC
(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.
Comment 11 Raphael Kubo da Costa 2011-05-17 04:07:03 UTC
(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.
Comment 12 Magnus Bergmark 2011-05-17 10:43:10 UTC
(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.
Comment 13 Raphael Kubo da Costa 2011-05-17 15:08:45 UTC
Oops, sorry :) Indeed, I was able to reproduce it now.
Comment 14 Raphael Kubo da Costa 2011-07-18 22:48:09 UTC
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
Comment 15 Raphael Kubo da Costa 2011-07-18 22:48:13 UTC
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
Comment 16 Raphael Kubo da Costa 2011-07-18 22:50:06 UTC
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
Comment 17 Raphael Kubo da Costa 2011-07-18 22:50:15 UTC
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
Comment 18 Raphael Kubo da Costa 2011-07-18 22:51:37 UTC
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).
Comment 19 Raphael Kubo da Costa 2012-04-16 14:49:06 UTC
*** Bug 283460 has been marked as a duplicate of this bug. ***