Version: 2.2.4 (using 4.2.4 (KDE 4.2.4), Arch Linux) Compiler: gcc OS: Linux (i686) release 2.6.30-ARCH This is a behavior error that can also be considered a bug. Even if I start Kget manually, it simply quits after showing a notification saying it is exiting as there are no downloads in queue. If there is a delay of few seconds to select the directory for download, Kget quits with the same message Kget quits even if I have the preferences window open. I had to start a download that would atleast give me couple of minutes to hunt down and change the preference that was causing this behavior. Wanted to have some fun by changing the preference to "shutdown" after downloads are complete. This would have probably caused KDE to get in a loop of starting Kget at startup and shutting down almost immediately as Kget triggers shutdown since there are no downloads in queue. Well, didn't have the time or courage to try it out, but till this bug is fixed, it can be used to pull a nice trick on unsuspecting enemies :) "Execute after all downloads are finished" option should be made a little less draconian and should trigger only if the session has seen active downloads (either new or resumed). Or this option should be made more visible and easily accessible, and should ideally set or trigger for that session only. Designer in me says users will want this behavior only when there us a large download going on, and hence would suggest this option have two variants # A very visible button, preferably in main toolbar, to trigger shutdown of kget or computer after downloads are finished. This should apply for that session only, and user should set it again when required in a future session. # Existing option in Advanced preferences should enforce this behavior across sessions if enabled, as it already does, but only if that particular session has seen a active download (new or resumed). And the exit notification should have a option to cancel the exit. If a user enables the exit trigger when a large download has been queued, the present behavior is pretty annoying when he opens kget again. PS: Exit trigger is not active when clipboard monitoring is on. So switch off clipboard monitoring if enabled before testing
Actually (trunk) kget doesn't quit on start if the queue is empty (or all transfers are completed) and the option to quit it is enabled. It should be checked in 4.3 if the behaviour has been fixed.
*** Bug 194784 has been marked as a duplicate of this bug. ***
Well marking this as fixed then as KDE 4.4 is not too far away... Lukas