71657 - Show progress and success for downloads in file icon

Status: RESOLVED DUPLICATE of bug 548763

(Core Graveyard :: File Handling, enhancement)

Description

[Andrew Thompson]

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.

Comment 1

[Matthew T (active 1999-2002)]

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.

Comment 2

[timeless]

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...

Comment 3

[Matthew T (active 1999-2002)]

Ok, this bug can be for the Mac impl, the Windows impl should be a separate bug.

--> File Handling, lordpixel.

Comment 4

[Jo Hermans]

Shouldn't we move this to Mac OS X, since System 8.5 isn't supported anymore ?

Comment 5

[Simon Paquet [:sipaq]]

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".

Comment 6

[Andreas Lange]

Corresponding Camino bug 183884 resolved WONTFIX.

Comment 7

[François Maurit]

(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

Comment 8

[Jo Hermans]

*** Bug 308210 has been marked as a duplicate of this bug. ***

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 326054 has been marked as a duplicate of this bug. ***

Comment 10

[Mike Beltzner [:beltzner, not reading bugmail]]

cc'ing mano, lord of all things OSX PPish ...

Comment 11

[Jo Hermans]

*** Bug 335153 has been marked as a duplicate of this bug. ***

Comment 14

[Jason Sonnenschein]

Attachment: mac google chrome dock badges

Comment 15

[Jason Sonnenschein]

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

Comment 16

[Jason Sonnenschein]

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

Comment 17

[Jason Sonnenschein]

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

Comment 18

[Jason Sonnenschein]

Attachment: Initial code towards a patch

Comment 19

[Jason Sonnenschein]

Attachment: v2

Comment 20

[Josh Aas]

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.

Comment 21

[Benoit Girard (:BenWa)]

Attachment: Implementation using badgetext

Comment 22

[Benoit Girard (:BenWa)]

Attachment: WIP

I'd be willing to finish and land this patch if people like the screenshot. Any feedback?

Comment 23

[Markus Stange [:mstange]]

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.

Comment 24

[Benoit Girard (:BenWa)]

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.

Comment 25

[Frank Yan (:fryn)]

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).

Comment 26

[Benoit Girard (:BenWa)]

I've discussed this with shorlander and we decided it's not worth shipping.