Removing incompletely downloaded files

[humdinger]

This is hrev547.

Wouldn't is be better if a partly downloaded file is automatically removed when pressing the "Remove" button in Web+'s Downloads window? At least I see no reason to keep an incomplete download around...

[mmadia]

Is it planned to implement/support resuming downloads like Net+?

[pulkomandy]

I'd like to be able to resume downloads, yes. However, we really need the "progress" icon overlay back, so that it's clear the file isn't downloaded yet.

[phoudoin]

I guess that Net+ was actually compositing a progress bar over the icon and setting it as the specific file's icon. We could do that too, or wait that, one day, Tracker support an icon overlay feature.

The thing about the "manual" way is that it works for any app that show file icon, not just Tracker / Deskbar.

[pulkomandy]

It's a bit more tricky to do using HVIF icons, but certainly possible. I'm not sure there are many apps showing file icons without using tracker PoseView, anyway. Deskbar is irrelevant, it doesn't show downloading files?

[stippi]

It is only slightly more tricky using HVIF. The classes necessary for this are contained in libicon.a, and end up in libbe. The header files and the code strips functionality which is only needed by Icon-O-Matic, but there should be enough left, or it should be easily enabled, so that one can add any shape one desires to an Icon object.

The most "complicated" step may turn out to be getting to the actual resource which contains the icon that ends up being used. For example, when you download a .ZIP, its no use to get the ZIP icon bitmap, you need to figure out where this actually comes from (the ZIP MIME-type file) and load it from there manually as a libicon.a "Icon" instance. But maybe IconUtils can be extended for that. From there, it's easy to add shapes to that icon and export it as file attribute, again using functionality from libicon.a (FlatIconExporter, if memory serves).

As far as what the best way to do it would be... I don't know. Apps other than Tracker only actually benefit if they contain a mechanism to live-update the icons of files they show based on node monitoring. But it would certainly be useful as a first implementation.

[pulkomandy]

The MIME type can be sniffed properly only after the download is done. Since the file is not useable before that anyway, I'd go with a generic 'download' icon, and ideally, have a double click open Web+ download window and resume the download if it's paused/stopped.

[phoudoin]

I was also considering using a "downloading" generic HVIF icon on which we add two rectangular shapes as a progress bar.

And I also agree, the default app for these pending / canceled / paused downloads should be Web+, not the final type default one.

[phoudoin]

Replying to pulkomandy:

The MIME type can be sniffed properly only after the download is done.

IIRC, we do that earlier than later. Each trunk of data received, we try to detect MIME type and set it accordingly if one match.

[humdinger]

Replying to phoudoin:

IIRC, we do that earlier than later. Each trunk of data received, we try to detect MIME type and set it accordingly if one match.

I'm for sticking to setting the correct icon as soon as possible and take the add-overlay-route. I'd like to recognize the downloading file by its icon, if possible.

Coming back to the original ticket issue: Never minding if Web+ can continue paused downloads (which would be a very nice feature), I think if a user is pressing "Remove" while downloading or after pausing/stopping and it becomes thus incomplete, the incomplete file should be deleted (put into Trash).

There's still a bit of a risk of confusing removing/deleting a file, i.e. what puts the file into Trash and what just removes the entry from the download manager list. Maybe we could see if moving to icon-buttons instead of text-buttons can resolve that. But that's for another ticket...

[phoudoin]

Well, currently we do have "Remove completed" and "Remove missing" buttons which, AFAICT, both just clear the list from completed/missing downloads respectively and don't delete any file.

Maybe a "Clear" button will be more semantically valid, and some option to allow cancel *and* delete automatically paused/stopped incomplete download files on clear command? I fear that's not most end user will expect, though.

[luroh]

Moving Web+ enhancements out of R1 milestone.