Version: (using KDE 4.3.1) OS: Linux Installed from: Ubuntu Packages When dropping a URL from Akregator or other app, the destination doesn't add "/whateverfilename" to the end of the default destinations folder string in the dialog-box that appears. Trying to continue without copying the filename with the slash to the destination string, manually, will attempt to write the file as the name of the folder used to store downloads, set in options, usually reporting the folder already exists. This has to be fixed or new users to linux/gnu will be pulling hairs out.
On current trunk the behaviour has been changed a bit, but it is not still acceptable. Steps to reproduce: 1) open konqueror and go to www.kernel.org 2) open kget window 3) drag the "latest stable kernel" (a .tar.bz2 file) to kget window -> the "new download" dialog is opened, the destination is a folder Here there are two choices: A) press "OK" -> kget opens the "save as" dialog asking for the file name, the default file name is the correct name of the file dropped. B) you can manually write the destination file name after the proposed destination folder. == considerations == It is fine that in "case A" it opens the "save as" when the file name has not been specified but the default behaviour should be that the file name should already be on the destination in the first dialog. The current behaviour force the user to confirm *two* dialog windows for starting a download. I think that one dialog could be enough. What do you (reporter and developers) think about?
Created attachment 36801 [details] Picture of KGet after adding url. Missing filenamein destination strings No filename put in destination strings after dropping a url to KGet window or drop-widget. Picture contains two steps. THe first step is what is produced after dropping the url. The second stage is pressing 'OK'.
(In reply to comment #2) > Created an attachment (id=36801) [details] > Picture of KGet after adding url. Missing filenamein destination strings > > No filename put in destination strings after dropping a url to KGet window or > drop-widget. Picture contains two steps. THe first step is what is produced > after dropping the url. The second stage is pressing 'OK'. I've included a screen shoot as mine is not adding the filename after pressing 'OK". It requires I type or paste in the filename everytime, making is very annoying. Computers are supposed to work for you not the other way around. If I press 'Suggest' button in the second stage of the picture attached, KGEt simply adds "_1" to the end of the folder name. Could KGet be confusing the folder name as it has a space in my situation?
The space is not the problem... I know about this problem and it's on my list to fix urgently, I'll see when I have time... :) Lukas
SVN commit 1022084 by lappelhans: *Move from QAbstractItemModel to QStandardItemModel *Move tray_newproto.* to tray.* and remove old tray implementation... *When dropping a file onto kget, use the file's name as destination automagically BUG:206704 CCMAIL:kget@kde.org M +7 -9 CMakeLists.txt M +21 -17 conf/transfersgroupwidget.cpp M +2 -0 core/handler.h M +18 -16 core/kget.cpp M +2 -2 core/kget.h M +1 -1 core/transfergroup.cpp M +337 -331 core/transfertreemodel.cpp M +68 -17 core/transfertreemodel.h M +1 -0 main.cpp M +4 -20 mainwindow.cpp M +1 -1 tests/testkget.cpp M +33 -11 ui/newtransferdialog.cpp M +3 -0 ui/newtransferdialog.h M +2 -17 ui/transfersview.cpp M +0 -1 ui/transfersview.h M +25 -17 ui/transfersviewdelegate.cpp A ui/tray.cpp ui/tray_newproto.cpp#1022055 [License: GPL (v2+)] A ui/tray.h ui/tray_newproto.h#1022055 [License: GPL (v2+)] D ui/tray_newproto.cpp D ui/tray_newproto.h M +5 -2 ui/viewscontainer.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1022084