Bug 179843 - kget doesn't start downloading at once
Summary: kget doesn't start downloading at once
Status: RESOLVED FIXED
Alias: None
Product: kget
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KGet authors
URL:
Keywords:
: 177803 180151 182479 185684 197481 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-01-06 21:37 UTC by Giovanni Venturi
Modified: 2010-08-19 13:48 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Venturi 2009-01-06 21:37:44 UTC 
Version:           2.1.87 (using 4.1.87 (KDE 4.1.87 (KDE 4.2 >= 20090101)), compiled sources)
Compiler:          gcc
OS:                Linux (i686) release 2.6.28-desktop

It's not possible that KGet for KDE 4.2 doesn't start downloading at once the file in its list added by konqueror integration. I have to go on file with the RMB and say start downloading... It's a unuseful complicated procedure. Change this behaviour, please.
Comment 1 Lukas Appelhans 2009-01-06 22:55:09 UTC 
This is, because the Download-Group (default one, not visible in the MainWindow) has the "Stopped"-State... we will rework the Download-Group stuff with KDE 4.3,  but I think we can make the group's default state to "Start" in KDE 4.2 :)

Lukas
Comment 2 Lukas Appelhans 2009-01-09 18:54:23 UTC 
*** Bug 180151 has been marked as a duplicate of this bug. ***
Comment 3 Lukas Appelhans 2009-01-11 02:29:18 UTC 
Ok I fixed this now, the default group state is now running...

Lukas
Comment 4 mtz.inc .. 2009-01-11 20:06:44 UTC 
just wondering where is this fixed? on kde 4.2 branch or on trunk? ..i am running kget from trunk(revision 909501) and the problem is still there .. i still have to right click and click "start" twice for kget to start downloading
Comment 5 Lukas Appelhans 2009-01-11 20:43:47 UTC 
It's in both, you need to delete your .kde4/share/apps/kget/transfers.kgt though...

Lukas
Comment 6 Lukas Appelhans 2009-01-19 12:51:01 UTC 
*** Bug 177803 has been marked as a duplicate of this bug. ***
Comment 7 Lukas Appelhans 2009-01-30 20:21:07 UTC 
*** Bug 182479 has been marked as a duplicate of this bug. ***
Comment 8 Lukas Appelhans 2009-03-12 12:59:12 UTC 
*** Bug 185684 has been marked as a duplicate of this bug. ***
Comment 9 Tobias G. Pfeiffer 2009-05-26 20:12:47 UTC 
Indeed, the transfers.kgt file needs to be deleted, then this problem disappears. Is there a possibility to do this automatically if it is detected that this file causes problems?
Comment 10 Dario Andres 2009-06-24 17:49:27 UTC 
*** Bug 197481 has been marked as a duplicate of this bug. ***
Comment 11 squan 2010-07-24 11:41:25 UTC 
I have a fresh opensSUSE-11.3 (kget-4.4.4) install and ran into this.
As the default state of the default group is fixed it seems
that this can get lost while using kget.
Please reopen
Comment 12 Lukas Appelhans 2010-08-05 23:08:42 UTC 
It's also configurable in trunk... so the closed state is justified...

Lukas
Comment 13 Matthias Fuchs 2010-08-18 17:52:37 UTC 
SVN commit 1165233 by mfuchs:

Do not stop the Schedulers when quitting. That way the Policy of the TransferGroups remains unchanged.
That means that Transfers don't get stopped now before they are destroyed.
Might be related to
CCBUG:179843

 M  +0 -2      mainwindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1165233
Comment 14 Matthias Fuchs 2010-08-19 13:48:10 UTC 
SVN commit 1165440 by mfuchs:

Fowardport r1165233
Do not stop the Schedulers when quitting. That way the Policy of the TransferGroups remains unchanged.
That means that Transfers don't get stopped now before they are destroyed.
Might be related to
CCBUG:179843

 M  +0 -2      mainwindow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1165440