Show progress and success for downloads in file icon

RESOLVED DUPLICATE of bug 548763

Status

--
enhancement
RESOLVED DUPLICATE of bug 548763
18 years ago
3 years ago

People

(Reporter: lordpixel, Unassigned)

Tracking

({helpwanted, platform-parity})

Trunk
All
Mac OS X
helpwanted, platform-parity

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: p-safari)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

18 years ago
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

Comment 2

18 years ago
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...

Updated

17 years ago
Blocks: 36776
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

Comment 4

16 years ago
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

Comment 6

14 years ago
Corresponding Camino bug 183884 resolved WONTFIX.

Comment 7

14 years ago
(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

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

Updated

13 years ago
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 ...

Comment 11

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

Updated

11 years ago
Duplicate of this bug: 401437
QA Contact: zach → file-handling

Updated

9 years ago
Duplicate of this bug: 549086
Created attachment 429331 [details]
mac google chrome dock badges
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
Created attachment 430534 [details]
Initial code towards a patch
Attachment #430534 - Flags: review?

Updated

9 years ago
Attachment #430534 - Attachment mime type: application/octet-stream → text/plain

Updated

9 years ago
Attachment #430534 - Flags: review? → feedback?(joshmoz)

Updated

9 years ago
Attachment #430534 - Flags: feedback?(joshmoz)
Created attachment 430542 [details]
v2
Attachment #430534 - Attachment is obsolete: true
Attachment #430542 - Flags: feedback?(joshmoz)

Comment 20

9 years ago
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)

Updated

9 years ago
Hardware: PowerPC → All
Created attachment 666815 [details]
Implementation using badgetext
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.

Updated

6 years ago
Assignee: lordpixel → nobody
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)

Updated

6 years ago
Status: NEW → RESOLVED
Last Resolved: 6 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.