Opened 14 years ago
Last modified 10 years ago
#7061 new enhancement
Removing incompletely downloaded files
Reported by: | humdinger | Owned by: | stippi |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Applications/WebPositive | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Change History (11)
comment:1 by , 14 years ago
comment:2 by , 11 years ago
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.
comment:3 by , 11 years ago
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.
comment:4 by , 11 years ago
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?
comment:5 by , 11 years ago
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.
follow-up: 8 comment:6 by , 11 years ago
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.
comment:7 by , 11 years ago
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.
follow-up: 9 comment:8 by , 11 years ago
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.
comment:9 by , 11 years ago
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...
comment:10 by , 11 years ago
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.
comment:11 by , 10 years ago
Milestone: | R1 → Unscheduled |
---|
Moving Web+ enhancements out of R1 milestone.
Is it planned to implement/support resuming downloads like Net+?