Version: v0.8.3 (using KDE 3.1.9) Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB-athlon Currently I have kget setup in my autostart directory so its already loaded before I need to download something. A problem is it takes a few minutes to actually load the program. I think this is due to me still having 338 transfers, but all of which are completed. I figure kget is checking all of these as its starts up to see if it needs to download them, etc.
Created attachment 2708 [details] My big transfer log Here is my big transfer log (~350 items still in it). Its renamed with -orig at the end because it was taking forever for kde to start with it loaded. Kget takes approxately 1-2 minutes to load up with this transfer load (located in .kde/share/apps/kget). Please fix this before 3.2, as kget is very handy for downloading with, but once you build up a large enough list of previous downloads, it becomes unusable. There is also not an easy way to delete them from the list (except to have them cleared when finish, which I don't like). I will file another bug for that though.
Created attachment 4468 [details] Changes individual dialog creation behaviour
Created attachment 4469 [details] Nothing to see here just new var
Created attachment 4470 [details] Dont do html strip on log when closing
Created attachment 4471 [details] Fixes leave dialog open weirdness Please review this code I'm not sure I fully understood what original code was doing. When I clicked leave dialog open checkbox on an individual download kget would quit when download finished due to autoshutdown when list empty setting, even though there were still queued and paused items. This seemed to fix anyway.
Patches above :) This bugged me so much I fixed it! Kget is currently very broken for large file lists. I tried downloading Suse9 ftp edition with kget and it wasn't pretty. These patches change behaviour of transfer list objects so that the individual dialog windows are not created unless beginning or resuming a transfer or unless the user explicitly requests that it opens. This fixes the appalling startup times for large transfer lists. At least the startup becomes acceptable short anyway. It seems to fix 57251 regarding cpu usage when kget window is visable and possibly others relating to performance issues. Also fixes unreported bug where closing kget takes ages for long file lists due to the time it takes to remove html from the log file. So the log will be in html and about twice the physical size but kget closes without using 100% cpu for minutes on end with large lists. P.S if the code looks weird I only know Java and Fortran, I cant even do hello world C++ :) Thankyou KDevelop devs!
I hope these work as I haven't been using kget for a while because of this all. I'll let you know after I see these commited to CVS (and fix my cvs build, hasn't been compile for the past couple days).
This bug is not valid anymore for KGet in trunk (KDE 4) due to the completetly new handling of transfer lists.