Version: v0.8.5 (using KDE 3.5.0 Level "a" , SUSE 9.2 UNSUPPORTED)
Compiler: gcc version 3.3.4 (pre 3.3.5 20040809)
OS: Linux (i686) release 2.6.8-24.19-default
when konqueror asks me what to do with a file i'm downloading, and i hit "save as", kget used to show me a kfileselection dialog (or whatever its called), where i could select the target directory, and change the target filename.
now (since kde 3.5), it shows me a directory selection dialog, and I can't change the file name.
With some misconfigured webservers that send filenames like "index.php?fileid=qw786342ir4hz23876e7kjdfh8723z4r", this is not funny.
Works as expected with SVN (branch 3.5, R-497051). Looks like it's been fixed before it was reported.
seems that this was some weird unconfigurable configuration setting (i.e. something with no frontend anywhere in the configuration dialogues), since killing kget, deleting its rc file, then starting kget fixed it for me...
it is back...
and this time, killing kget and deleting kgets rc file didnt help at all.
it seems to be related to the mime type of the downloaded file, for some mimetypes the directory selection dialog appears, for others the proper file name dialog appears.
download anything from source forge, works.
download anything that gets announced as application/octet-stream, doesnt work.
Can you give an URL where this happens please. Looks like I can't find one.
oh btw that exact url ends in an "illegal address" for me when i
select a directory, following by an "download complete" together with
the file having been downloaded to the exact directory i chose.
Not a very good test case. The server seems to have problems, I can't even ping it. In both konqueror and kget, I get "Could not connect to host mine.myphotos.cc (port 6966)" errors. When I retry often enough it works sometimes, but konqueror is not calling kget at all( which may be considered a bug in konqueror). When I do "file->paste" in kget (and the server can be reached) then I get the normal file-dialog and everything works as expected.
Give me a better test case or I'll close as "works for me".
The first server gives me a timeout. On the second, using the links on http://www.point-blank.cc:7001/ I can do a "RMB->download with kget" and the normal file-dialog opens. I can spot no problem here, except maybe that "LMB->Save as.." is not calling kget, but konqueror is doing the job itself, again with a normal file-dialog.
I have to assume that whatever problem you have here, it's fixed by now (I'm using kdelibs and kget from SVN).
both links work for me.
in both cases, kget comes up with a "choose directory" box.
and with the links on the tracker page, with LMB->save as, it's "choose directoy" boxes again, in each case.
and what you say is basically "i can't reproduce your problem with a totally different software version when doing something different from what you do when the bug hits you, so it must be fixed by now."
just for the record, i can easily reproduce this bug on three different systems:
1. a machine running suse 9.2 with kde 3.5 from suse supplementary
2. a second machine like the one above, using a different user account
3. a third machine running suse 10.0 with kde 3.5 from suse supplementary
oh and before you say it...
the suse package maintainer explicitely told me to file that bug here, he said they did not run any parches against kde 3.5 which would possibly warrant such behaviour...
ok, you might be right there...
so far, i tried to reproduce this behaviour in kubuntu 5.10 running in a vmware, with kde 3.5.0 packages from the apt repository mentioned in http://kubuntu.org/announcements/kde-35.php, and while on "suse kde" i get the "choose directory" dialog, which (according to its title) is from kget, when i download those torrent files in kubuntu kde (at the very same moment, on the very same internet connection), i get the proper "save as" dialog...
Next try shall be pcbsd 1.0 which comes with kde 3.5 as well. I'll post updates here, and if the results are the same as in kubuntu, I'll hit adrian over the head with them until he tells me what they broke with kget.
ok, its also not reproduceable on pcbsd 1.0.
Guess I'll shove it back in the face of the kde people at suse.
but lets keep it open until they solve it.
I tracked it down to this commit breaking it: http://websvn.kde.org/branches/KDE/3.5/kdenetwork/kget/main.cpp?rev=490685&view=rev
And you can only reproduce it with the SUSE KDE "3.5" supplementary rpms because they actually contain a recent snapshot of the KDE 3.5 branch much newer than 3.5.0.
then why couldn't rainer reproduce it with kdelibs and kget from svn?
ah well, as long as its been confirmed and going to be fixed now...
Sorry, my fault, I can reproduce it now.
*** Bug has been marked as fixed ***.
good. but will the fix make it into 3.5.1?
after all, the release schedule said 3.5.1 would be tagged on jan 20th...
> but will the fix make it into 3.5.1?
No. SUSE will pick up the bugfix for Beta 3.
beta 3 of what?
suse 10.1? that would be... bad... because i'm going to stick with 9.2 for a while...
did this fix make it into kde 3.5.1? its not listed in the changelog...
This didn't make it into KDE 3.5.1. And I meant SUSE 10.1 Beta 3 in #19.
this also did not make it into kde 3.5.1 in "supplementary" from suse :(
So, which "official" kde release will this fix be in? 4.1.x?
I get the problem too. There is some unintuitive work around:
In the "directories" tab, you add an empty (no folder specified) entry for all files (that is *). I hope this is not the case in 3.5.1 ;)
This bug is fixed in KDE 4.1 trunk...