[kde-linux] Kget "My Downloads" [Is this MS Windows?]

[James Tyrer]

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