Bug 197675

Summary: kget new download dialog sets incorrect name for target file
Product: [Applications] kget Reporter: anton <benderamp>
Component: generalAssignee: KGet authors <kget>
Status: RESOLVED FIXED    
Severity: normal CC: dextermagnific, markinhos, pfeiffer
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description anton 2009-06-24 00:51:25 UTC
Version:            (using KDE 4.2.90)
OS:                Linux
Installed from:    SuSE RPMs

I use kget as dowload manager for konqueror (corresponding checkbox is selected in kget options)

1. Click on downloadable file link on a webpage (http://scoreninja.appspot.com/, find scoreninja1.2.jar there)
2. Slick Save As.. in the opened dialog
3. the New Download dialog would appear with values:
URL=http://scoreninja.appspot.com/scoreninja1.2.jar
Destination=/home/user/
4. Click on the directory chooser button to the right of Destination field
5. Navigate to the Desktop directory and click ok
6. This would return to New Dowload dialog with the new value of the Destination field:
Destination=/home/user/Desktop/user
7. Click OK - nothing would happen, dowload would not be queued

8. If remove the last item from destination path:
Destination=/home/user/Desktop/

the download would start ok and the scoreninja1.2.jar would be saved to Desktop directory
Comment 1 Carsten Pfeiffer 2009-06-24 12:48:04 UTC
I don't see the 'user' part after the Desktop directory, but I see another problem there: whatever you enter as a filename, only the directory part will be used. I.e. if you enter /tmp/foo.jar either with the filedialog or directly into the edit field, the download will be saved to /tmp/scoreninja1.2.jar instead of /tmp/foo.jar.
Comment 2 Lukas Appelhans 2009-06-24 12:52:16 UTC
Regression from your patch maybe? It *used* to work before...

Lukas
Comment 3 Carsten Pfeiffer 2009-06-24 13:43:33 UTC
Yes, kind of. The parameter destDir in KGet::addTransfer() is used by callers not only to pass the target directory, but also to pass the complete path to the target file (i.e. not a directory, but file).

That was not handled correctly (but fixed now). I can't say anything about the original report though -- I don't get the weird additional "user" in there.
Comment 4 anton 2009-06-24 14:22:51 UTC
>That was not handled correctly (but fixed now). I can't say anything about the
original report though -- I don't get the weird additional "user" in there.

user means current user name - in my case this is benderamp:
Destination=/home/benderamp/Desktop/benderamp

This seems to be more directory open dialog issue, rather then kget (or kget misuses it).

This is what I do in more details:

1. Start downloading - the Destination=/home/benderamp/ by default
2. Press directory chooser button - receive directory chooser dialog with title KGet
2.1 The location directory is /home
2.2 Directory "benderamp" is selected inside central file view
2.3 File name field at the bottom also equals "benderamp" (this is important)
3. Click on the selected directory with mouse - enter /home/benderamp directory (important to do this with mouse, not with "Ok" button)
3.1 File name field at the bottom value still equals "benderamp"
4. Click on the Desktop directory with mouse - enter /home/benderamp/Desktop directory
4.1 File name field at the bottom value still equals "benderamp"
5. Press "Ok" button - the Destination value now equals "/home/benderamp/Desktop/benderamp"

So, I can understand why this happens - it takes current directory value (which is Desktop) and treats "benderamp" (which were set as default value in file name field) as a new file name inside it.



There is another scenario - very similar, but a bit different:

1. Start downloading - the Destination=/home/benderamp/ by default
2. Press directory chooser button - receive directory chooser dialog with title KGet
2.1 The location directory is /home
2.2 Directory "benderamp" is selected inside central file view
2.3 File name field at the bottom also equals "benderamp" (this is important)
3. Press "Open" button - this would enter /home/benderamp directory (this is key difference from the previous scenario)
3.1 File name field at the bottom is now empty
4. Click on the Desktop directory with mouse - enter /home/benderamp/Desktop directory
4.1 File name field at the bottom is still empty
5. Press "Ok" button - it will not work (because file name field is empty)
6. Type some text in the file name field (123) and press Ok

the Destination value now equals "/home/benderamp/Desktop/123"
Comment 5 anton 2009-06-24 14:41:54 UTC
I think file destination picker behavior can be changed in 2 ways:

1. Make it pure directory choose dialog - Ok button would always open current
directory, no filename value should be required - the original file name would
always be used for target file

2. Duplicate konqueror's "rightclick/Save Link As..." context menu behavior.

If I save link in this way, I receive file chooser dialog with "scoreninja.jar"
value set to file name field by default - I can navigate to any directory and
this value will remain the same (only the path would change), or I can change
filename by hands or select some file (not directory) to replace. So, chosen
destination in not directory, but path to concrete file.

In this case, when I first open "New Download" dialog, the destination value
would be not just "/home/benderamp", but "/home/benderamp/scoreninja.jar"
Comment 6 Dario Massarin 2009-08-19 15:29:08 UTC
*** Bug 204096 has been marked as a duplicate of this bug. ***
Comment 7 Lukas Appelhans 2009-09-21 13:42:14 UTC
*** Bug 208072 has been marked as a duplicate of this bug. ***
Comment 8 Lukas Appelhans 2009-12-25 01:29:48 UTC
Ok, KGet should have the behaviour as described in your last comment in KDE 4.4...

Lukas