Closed Bug 71657 Opened 22 years ago Closed 9 years ago

Show progress and success for downloads in file icon

Categories

(Core Graveyard :: File Handling, enhancement)

All
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 548763

People

(Reporter: lordpixel, Unassigned)

References

Details

(Keywords: helpwanted, platform-parity, Whiteboard: p-safari)

Attachments

(4 files, 1 obsolete file)

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
Keywords: helpwanted
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
Keywords: pp
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".
OS: Mac System 8.5 → MacOS X
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. ***
Duplicate of this bug: 401437
QA Contact: zach → file-handling
Duplicate of this bug: 549086
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
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
Attached file Initial code towards a patch (obsolete) —
Attachment #430534 - Flags: review?
Attachment #430534 - Attachment mime type: application/octet-stream → text/plain
Attachment #430534 - Flags: review? → feedback?(joshmoz)
Attachment #430534 - Flags: feedback?(joshmoz)
Attached file v2
Attachment #430534 - Attachment is obsolete: true
Attachment #430542 - Flags: feedback?(joshmoz)
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.
Attachment #430542 - Flags: feedback?(joshmoz)
Hardware: PowerPC → All
Attached patch WIPSplinter Review
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.
Assignee: lordpixel → nobody
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.
Attachment #666815 - Flags: ui-review?(shorlander)
Status: NEW → RESOLVED
Closed: 9 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.