Version: (using KDE 4.3.0) Installed from: Gentoo Packages Prior to kde 4.3, when I downloaded something with kget, it went in the queue and started when it got to its turn in the queue. The only save dialog was the one that kget popped up when I dragged the the link onto the drop target. kget doesn't seem to work that way anymore in kde 4.3. Now, the same save dialog pops up as before when I drag the link onto the drop target - or the main kget window - but it isn't put into the queue. There is a delay, and then the normal konqueror save dialog pops up asking me _again_ where I want to save the file. _Then_ and _only_ then does the download appear in the kget window. Not only is the extra save dialog redundant, but since kget doesn't just put the downloads in the queue, it's impossible to actually queue up downloads. When I dragged multiple links onto the the drop target in rapid succession, only one konqueror save dialog opened (after the delay). That one download was not put into the queue until the konqueror save dialog had been used, and none of the other downloads ended up in the queue or caused the konqueror save dialog to pop up. An additional irritation is that while the kget save dialog will let me overwrite a file (after warning me about it), the konqueror save dialog not only warns me about it again, but won't let me overwrite it. It insists that I rename it. The konqueror save dialog should not be popping up unless you select the browse button on the kget save dialog to change the directory to save to. Also, after downloads have been added with the kget save dialog, they should be queued up in kget's queue without any more dialogs popping up about them. The current behavior is a major regression that makes kget pretty much useless in comparison to just using konqueror's normal download dialog on its own.
I'm trying to sort out the different issues that you found: - when adding a download (via drop target or anything else), the download is not queued automatically - when dropping a URL onto the drop target, you get the new-transfer dialog - when leaving the target directory as is in the new-transfer dialog, or specifying just a directory instead of a directory + filename, then a filedialog pops up, asking you for the filename (and optionally directory) not even taking the filename of the url you want to download into account I see the following options to fix the last two problems: - fix the new-transfer dialog by not displaying a directory as target, but directory + filename (where the filename is by default derived from the source url) - do not display the new-transfer dialog, but the plain file dialog, which provides the same options with less clicks The latter option would also spare us from fixing other issues in the new-transfer dialog - doesn't remember the last used directory - appears to provide a history for the target (it's a combobox), but there's always just one entry with the current target url - does not provide auto-completion
The newtransferdialog also displays directory + filename (at least before your changes). But indeed, it's a bit worrying sometimes, the only problem I saw was getting the filename from the server when for example a download-script is used... (download.php which results in a differen filename for example xyz.zip) Lukas
So well, I think this is fixed in latest KGet... If you want to have downloads directly added to the Queue instead of having a dialog pop up, use the Default Directories and turn off the "Default directories as suggestion" option... Thanks Lukas