Bug 172245 - default download folder field in KGet is useless
Summary: default download folder field in KGet is useless
Status: RESOLVED FIXED
Alias: None
Product: kget
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-06 01:15 UTC by Alexey Chernov
Modified: 2008-12-16 19:59 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Chernov 2008-10-06 01:15:31 UTC
Version:            (using KDE 4.1.2)
Compiler:          GCC 4.1.2 Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.1.2/configure --prefix=/usr --libexecdir=/usr/lib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=c,c++ --disable-multilib Thread model: posix
OS:                Linux
Installed from:    Compiled From Sources

The field "Place new downloads inside default folder: " in KGet settings is completely useless, because entering there has no effect with every directory. The next settings opening shows the old value there, for me it's a home directory. The same is when exiting and opening KGet again. Though there're some effect, because sometimes after change new downloads places in the right dir, but the value still doesn't change. I have special directory settings in certain tab, perhaps this is the reason.
To reproduce:
1. Make some directory settings in 'Directories' tab.
2. Open settings and enter any different directory as default. Confirm it.
3. Open settings again and check the value. It didn't change.
4. Exit KGet and open it, open settings and check the value. No change.
5. Try downloading the file for which no directory defined in Directory tab. Sometimes it is downloaded to the right place that you've typed in #2.
Comment 1 Lukas Appelhans 2008-12-16 19:59:57 UTC
This is fixed in current trunk...

Lukas