Bug 190500

Summary:	Konqueror integration: get from cache/KPart where possible rather than redownload
Product:	[Applications] kget	Reporter:	peaches <pzcdyhbb0nzq9layi4mcj1hhp>
Component:	konqextension	Assignee:	KGet bugs <kget-bugs-null>
Status:	REPORTED ---
Severity:	wishlist	CC:	mat69
Priority:	NOR
Version First Reported In:	unspecified
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description peaches 2009-04-24 11:10:27 UTC

Version: trunk: KDE r957442, qt-copy r942255 (using Devel)
OS: Linux
Installed from: Compiled sources

Saving things like images from Konqoueror creates new downloads for KGet, which downloads new copies. Aside from getting entirely new copies, this can sometimes not work at all, if the website reacts differently based on "Referer:" http request header entry or something like that, which KGet can't necessarily know about or change.

I think both problems can be solved much of the time for Konqueror plugin to get any finished data it can from Konqueror cache or KHTML KPart first (I assume the KPart data and Konqueror cache are separate anyway, and getting from KPart where possible would work even if caching is off). Then the download could be automagically added to KGet as 100% finished with whatever pre- and post-handling goes on, like transfer history tracking and semantic tagging.

Seems like a bit of coding voodoo, but it would be nice.

Hopefully this can also be helpful for cases like for example you download a PDF and view it in Okular KPart inside Konqueror, then use Konqueror's Save As to get an instant KGet copy (right now I think the KPart's internal context menu doesn't send to KGet at al which may be another issue altogether...).

Now that I think about it, maybe KGet can simply poll all opened Konqueror instances for any URL that gets added to it, checking if any KParts or Konqueror cache has the URL's data already as a completed download, then start the voodoo magic.

Anyway.. something to think about.

Comment 1 Matthias Fuchs 2010-07-12 21:02:24 UTC

In general this could be done automatically and actually was.
You can tell KIO to use cached data if it is available.

Yet there is a backdraw and that is the reason it has been disabled: When you do a download but the resulting file is borked -- e.g. some data was transfered wrongly -- then redownloading it will still use the cached data.

Most likely we would also have to add this as configuration-setting, so that users could deactivate it, if it does not work.
In this case there would still be a problem though: If the download does not work how should the user connect this with the configuration option?

I am not sure if this feature would justify making the code even more complex and harder to understand. I will look into it and discuss it with Lukas when I have time.

Comment 2 Matthias Fuchs 2010-07-12 21:25:12 UTC

Hmm though looking at the rev you used it should have been still supported.