On Mac OS, Apple provide an API for easinly making temporary changes to icons. iCab (a fairly popular Mac onl browser) and MacIE5 both use this API to draw a progressbar in the icon for a file as its being downloaded. Every few seconds, this is updated to show the progress. If the file download completes sucessfully, the final "proper" icon for the file is set. If the file download fails for any reason, the fragment is given a broken icon, with a warning triangle. We should be leveraging this cool feedback technology also. On all platforms, if technically feasable.
I can imagine this being achieved on Windows, though by a rather hackish fashion. On Windows, the icon for a file is determined by its file extension. So what we'd do is have about 35 different file extensions for downloads. About 33 of these would be for showing download progress (perhaps .d00, .d01, .d02, ..., .d31, .d32). Each of these extensions would have its own icon stored in the Mozilla executable, these icons being identical except for the different state of the progress bar in each one. Then, as the file was downloaded, we'd rename it periodically so as to apply a different extension to it, giving it an icon commensurate with the proportion downloaded. The remaining two icons would be one for a download that did not finish (.dnf?), and one for a download that was in progress but where the progress was unknown (an icon overlaid with an indeterminate progress bar, rather than with a determinate progress bar). The really nice thing about this would be that where a download did not complete for whatever reason, you could just double-click the icon; Navigator would open (because it would be associated with that filetype), it would look in the file's `Comment' field or equivalent to see what the URL of the download was and what the final file extension was supposed to be, and it would then restart/resume the download. There would be all sorts of potential reasons for this turning out to be impossible, such as: * saving foo.jpg, and colliding with another file in the same folder which happened to be called foo.d17 or whatever (though we could just skip that extension on the way to the next one); * the ugly display of the suffixes in Explorer's file display (could we turn that into a feature, by using approximage percentage figures rather than 00 to 32?); * cluttering up the list of file types with all these near-meaningless extensions. I'm sure Timeless can think of more problems. :-) This probably needs to be split into two bugs, one for Mac OS and one for Windows.
Severity: normal → enhancement
Actually, that may be the hackish approach, but there is a sane approach too. Windows allows you to provide code in a dll that provides the file icons. So we could have a download progress db and a .mozdl file type which is owned by mozilla w/ icon services provided by our special dll which would check for info against the progress db (I'm not sure if we could piggyback w/ cache or some one else's db, that's an implementation detail). Double clicking the file would of course run moz and resume the download...
Ok, this bug can be for the Mac impl, the Windows impl should be a separate bug. --> File Handling, lordpixel.
Assignee: mpt → lordpixel
Component: User Interface Design → File Handling
Shouldn't we move this to Mac OS X, since System 8.5 isn't supported anymore ?
This bug is targeted at a Mac classic platform/OS, which is no longer supported by mozilla.org. Please re-target it to another platform/OS if this bug applies there as well or resolve this bug. I will resolve this bug as WONTFIX in four weeks if no action has been taken. To filter this and similar messages out, please filter for "mac_cla_reorg".
Corresponding Camino bug 183884 resolved WONTFIX.
(In reply to comment #6) > Corresponding Camino bug 183884 resolved WONTFIX. bug 183884 is about dock icon this bug is about file icon file icon showing progress is something safari does and as such, even if low priority, should be a target to be on par with this browser
*** Bug 308210 has been marked as a duplicate of this bug. ***
Summary: Show progress and sucess for downloads in file icon → Show progress and success for downloads in file icon
*** Bug 326054 has been marked as a duplicate of this bug. ***
cc'ing mano, lord of all things OSX PPish ...
*** Bug 335153 has been marked as a duplicate of this bug. ***
i think the new google chrome for mac dock badge is quite classy and intuitive... # of pending downloads with % complete pie chart in background... png attached
I found google's source code for this, fyi: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/dock_icon.h http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/dock_icon.mm
After lots of back and forth between Thunderbird, google chrome, and developer.apple.com, I think I have some code that can draw the badge, but I have no idea how to get it called when downloads start, stop, resume, finish, change progress amounts, etc. I was looking at NSdownloadsMangager and ProgressListener, etc, but I don't think I'll be able to figure it out. Attaching my progress and hoping someone else takes over
Created attachment 430534 [details] Initial code towards a patch
Attachment #430534 - Flags: review?
Attachment #430534 - Attachment mime type: application/octet-stream → text/plain
Created attachment 430542 [details] v2
Comment on attachment 430542 [details] v2 Thank Jason. Hopefully someone will pick up this bug. If someone does, probably best to talk to UI people (Faaborg?) about this first.
Created attachment 666816 [details] [diff] [review] WIP I'd be willing to finish and land this patch if people like the screenshot. Any feedback?
CC'ing some UX guys. There's some discussion about this in bug 548763, too, but I think the two approaches can be combined. And maybe we should restrict the fix for bug 548763 to Mountain Lion and only use the native progress bar, nothing custom drawn.
UX: any feedback on the current design? Finishing this patch isn't much work. We can leave the more fancy design for Mountain Lion and later.
Attachment #666815 - Flags: ui-review?(ux-review)
Comment on attachment 666815 [details] Implementation using badgetext Since shorlander was the one who brought this up in IRC, he's probably the best person to ask. I'll give my two cents: The problem with using badge text for this is that the badge is designed to alert the user, which is why the background color is red. We should never show progress with a red background color, because it implies that some went wrong or needs to be immediately addressed by the user. I don't think the added information of the percentage progress outweighs the misleading and distracting visual design of the badge text, especially given that we already provide the progress information in the download toolbar button (if you enable our almost-done downloads panel).
Attachment #666815 - Flags: ui-review?(ux-review) → ui-review?(shorlander)
I've discussed this with shorlander and we decided it's not worth shipping.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 548763
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.