Closed Bug 36776 Opened 25 years ago Closed 15 years ago

Show download progress in window icon

Categories

(SeaMonkey :: Download & File Handling, enhancement, P3)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: jruderman, Unassigned)

References

Details

Attachments

(2 files)

ZIP: Set of icons for download progress window
3.51 KB, application/zip
Details
OK, here is the animated gif from the GetRight download taskbar icon.
49.55 KB, image/gif
Details 
Quoting mpt@mailandnews.com from bug 35046:

"... show the progress by coloring in the window's icon -- that way you 
wouldn't even need the space required to show a percentage figure (in the 
Windows taskbar, etc); all you'd need is the icon square."

Not sure how many platforms this makes sense on.
This should be a dup of bug 35046. Either the window icon or the window title 
should show the progress, but not both. To have *three* different elements in 
the window showing download progress (the icon, the title, and the progress bar 
in the window itself) would just be silly.

The icon idea makes sense on Windows, on MacOS, and possibly on GNOME and KDE as 
well, but not on generic X.
Well, when the window is minimized, only two of those could be visible.  The 
icon has the disadvantage that it doesn't convey too much information (unless 
you squeeze text into it, which would be abusing the idea of an icon), and the 
title disappears when you have lots of windows open.
This is up to xpapps
Assignee: evaughan → don
Component: Progress Window → XPApps
Target Milestone: --- → Future
Depends on: 16213
Component: XP Apps → XP Apps: GUI Features
well since a minimized taskbar icon (on win32 at least) is only 16*16 the 
information conveyed therein is very little (one pixel for every 6 or so percent 
of progress) it would be useful to have both the percentage of progress upfront 
in the title as well as a changing icon, so the user can at least whether e.g. a 
long download is progressing or not. It is up to the design executon however to 
make it subtle and undisturbing.

Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
thanks,
	Vishy
Assignee: don → vishy
See also bug 69885.
I definetely think we should show the *progress* as a percentage (most precise
to see if download has stalled) *AND* in the icon as a quick visual clue. *Both*
yield subtly but significantly different types of info.

If we have and icon that changes state based on the completion - i suggest an
icon with 10 horizontal bars (10%, 20%,..., 100%), that change colors (green:
10-40%, yellow: 50-70%, red: 80-100%) as the download completes (see GetRight
taskbar icon).

PS. I believe this is a valuable and important feature for all "file leechers" :)

The icons I just uploaded have a small bar at the bottom, and an icon above it.
I'd like to see this icon become a nice IE-esque globe with the line connecting
to the computer, but just about anything could go there. The bottom bar's blue
and cyan colors match Netscape's icon colors.
arg. i know there are comments in another bug, i'll find them.
[ah, from bug 16213 :)]
------- Additional Comments From timeless@mac.com 2001-01-21 13:15 -------
has anyone seen netpositive's download icon states?  we could follow that 
approach, which is to show % done as a vertical bar.
small icon:
dimensions: 2x14, progress-color: red
border: 1px, color: dark-grey
large icon:
dimensions: 4x29, progress-color: red
border: 1px, color: dark-grey
shadow: 1px, color: black, direction: south-east

for small icon that means progress of 7% is indicated by another row of 2 
pixels.  for large icon progress of 3% is indicated by another row of 4 pixels.

it is possible w/ windows to composite icons on the fly, if we don't, we'd have 
to create 36 icon pairs that are mostly duplicates.

attachment 23108 [details] false color progress from net+
--
I'd also like us to use an overlay system, but for that we'll need an xp 
overlay api ...

plairo: i think your color choices are off, i'd expect green to mean 100% done 
[yellow for something 40-95%, red for 0-39% give or take]

however, please attach an animated gif of getright's progress [preferably 
showing at least increments every 10%]

-at the risk of getting this bug killed i'm redirecting it to UID because we 
clearly aren't ready to implement this feature.
Assignee: vishy → mpt
Component: XP Apps: GUI Features → User Interface Design
QA Contact: sairuh → zach
Target Milestone: Future → ---
At the end of the download (100%) the icon changes to a yellow smiley for about
a second and a configurable sound can be played (I have: "Your download is done").

Maybe we also only need ONE color since the progress is already being indicated
by two visial clues (percentage number and vertical bar).
I think Skewer's (2001-05-27 12:26) icons are too subtile. The actual progress
info is not visible enough (MUCH too small). Icons are small enough and the
progress should be *as large as possible* whithn these limited constraints.

The GetRight method is far superior -> see my cool animation attachment - my
fist animation ever ;)
Personally, I think a download progress icon that uses the entire 16x16 pixels
is a bit gaudy. Since we do have the percentage right next to it (the only time
we wouldn't would be if we ran downloads in the tray or if someone had an insane
number of apps running), it's reasonable to sacrifice a little visibility in the
interest of aesthetic appeal. I wrote a program to test out my icons and they
were visible enough at 800x600.
I run 1024 at home and 1280 at work - I have no interest in your microscopic
progress bars (no offense, you clearly put some work and thought into it).
However, we're talking about something a *quarter* the size of a thumbnail!

To make it look more esthetic, we could make each bar 3D-ish and really well
drawn and limit the number of bars to 10. Multicolored bard would further the
esthetic appeal :)
*** Bug 101367 has been marked as a duplicate of this bug. ***
If anyone has FTP Voyager from Rhino Software, its icons are very attractive -
round pie-charts that fill in from 12 o'clock to the right. A similar design
might be the most appropriate icon for this situation. I am quite familiar with
its icons since I use that program to download daily builds (reason: bug 18004).
This bug requires two things.
(1) Bug 71657 -- show download progress in the icon of the file itself.
(2) Bug 159742, which I've just filed -- show the icon of the file itself in the
    title bar.

Then, all that will be required to fix *this* bug, is code to update the icon 
in the title bar whenever it is updated in the file manager.

--> Download Manager
Assignee: mpt → blaker
Component: User Interface Design → Download Manager
Depends on: 71657, 159724
No longer depends on: 16213
QA Contact: zach → sairuh
Summary: [RFE] Show download progress in window icon → Show download progress in window icon
Sorry, (2) should be bug 159724, not 159742.
See also Bug 124798 for Mac OS X. :-)
QA Contact: sairuh → petersen
Here is my comment from bug 28385:

Why don't downloads fork to a helper app?  Is it too much to maintain a bunch 
of lightweight, one-function download windows?

As for downloads that don't have their own windows, I suggest WONTFIX because 
people generally want network activity to halt when they close its associated 
window.

Why is Bill Law not associated with these bugs -- isn't he in charge of 
downloads?  There is a design document that says he is.
Blocks: 28385
Product: Browser → Seamonkey
Assignee: bross2 → download-manager
QA Contact: chrispetersen
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug still applies to Seamonkey (and to Thunderbird). Please re-confirm it.
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
restoring NEW since this bug is still a valid enhancement.
Status: UNCONFIRMED → NEW
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: UNCONFIRMED → NEW
I don't see the SeaMonkey team actually working on this in anything but my wildest dreams where we have a few hundred programmers working full-time on the code, so I'm just being honest and declaring this WONTFIX. Please implement it as a SeaMonkey 2 add-on if you can, and if that one is widely being used, we can argue about including it by default, but not before that point.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: