On 04/19/2013 10:11 PM, Duncan wrote:
James Tyrer posted on Fri, 19 Apr 2013 17:51:40 -0700 as excerpted:
I find that KGet still
I think that kget may be a holdover from the dialup connection era.
I know I hardly used it, and actually haven't had it installed at all
for some time (years) now. I wasn't actually using it before that,
but I thought it was konqueror's download component, and thought
it'd break that if I uninstalled it. Once I figured out it was a
separate program that I never ran anyway, I uninstalled it.
Of course now I've uninstalled konqueror as well, since for file
browsing it uses the dolphin kpart anyway, so I have to have dolphin
installed for that and I might as well use dolphin (tho that's only
for the GUI non- image file management, gwenview for images/video,
and the mc "semigui" for sysadmin file management tasks), and
apparently even the konqueror devs consider it little more than a toy
for web browsing, explaining why it took so long to get anything
close to reasonable security certificate management, as well as why
the infamous 4.6 double-form-submit bug took two full monthly bug
cycles to fix. So firefox is my browser, and mc/ gwenview/dolphin
are my file managers, and there's simply no functional hole left for
konqueror to fill.
But back to kget. It being a holdover from the dialup era
Don't see what it has to do with dial up, but rather
file_length/connection_speed. I am out in the country and have only 150
KiB/sec and long files still exist. Since Konqueror has no builtin
download manager, KGet is necessary to see how downloads are
progressing, although FTP downloads can be handled as copying. Long
files are sometimes still interrupted although it is rarer. KGet does
have more features than the download managers built into Firefox and
Google-Chrome. It also has Torrent support built in.
that no longer has a real maintainer, and that is simply being held
together by hacks from some other kde dev when something breaks,
until it eventually gets to be no longer worth maintaining, would
explain the hacks you see in the code, etc.
This might explain why it wasn't fixed, but doesn't explain why it was
written wrong to begin with.
Meanwhile, kde5 aka kde frameworks is being designed to be far more
modular, and already they're gradually splitting up the formerly
huge monolithic tarballs into individual repos, with the core desktop
intended to be much smaller and all these individual apps that are
now part of the six-month core kde update and release cycle, will
probably be shipped separately and updated on their own schedule.
Does this mean that KDE-4 is already being abandoned by the developers?
Do you think that there is any chance that KDE-5 will ever work, or
will it just be the same story?
And kget might be one of the apps that gets dropped by the wayside in
the upgrade, since it's really not needed these days.
It would be better replaced with a browser plugin or component.
If it does get ported, it'll probably be on a rather long release
cycle, with little further work put into it besides the bare minimum
to keep it building and running.
OTOH, perhaps somebody new will take an interest and either develop
a fresh replacement for it, or will rewrite it and kill the hacks
that have built up over the years...
If the current code base is built on poor design, or hacking instead of
design, it might be better to start from scratch with a design.
--
James Tyrer
Linux (mostly) From Scratch
--
James Tyrer
Linux (mostly) From Scratch
___________________________________________________
This message is from the kde-linux mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde-linux.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
