Closed
Bug 36776
Opened 25 years ago
Closed 15 years ago
Show download progress in window icon
Categories
(SeaMonkey :: Download & File Handling, enhancement, P3)
SeaMonkey
Download & File Handling
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: jruderman, Unassigned)
References
Details
Attachments
(2 files)
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.
Comment 1•25 years ago
|
||
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.
Reporter | ||
Comment 2•25 years ago
|
||
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.
Comment 3•25 years ago
|
||
This is up to xpapps
Assignee: evaughan → don
Component: Progress Window → XPApps
Updated•25 years ago
|
Target Milestone: --- → Future
Updated•25 years ago
|
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.
Comment 5•24 years ago
|
||
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
Comment 7•24 years ago
|
||
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.
Comment 10•24 years ago
|
||
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 → ---
Comment 11•24 years ago
|
||
Comment 12•24 years ago
|
||
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).
Comment 13•24 years ago
|
||
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 ;)
Comment 14•24 years ago
|
||
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.
Comment 15•24 years ago
|
||
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 :)
Comment 17•23 years ago
|
||
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).
Comment 18•22 years ago
|
||
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
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 21•22 years ago
|
||
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
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•18 years ago
|
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Comment 22•16 years ago
|
||
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
Comment 23•16 years ago
|
||
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
Comment 24•16 years ago
|
||
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
Comment 25•16 years ago
|
||
This bug still applies to Seamonkey (and to Thunderbird). Please re-confirm it.
Comment 26•16 years ago
|
||
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
Comment 27•16 years ago
|
||
restoring NEW since this bug is still a valid enhancement.
Status: UNCONFIRMED → NEW
Comment 28•16 years ago
|
||
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
Comment 29•16 years ago
|
||
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
Comment 30•16 years ago
|
||
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
Reporter | ||
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
Comment 31•15 years ago
|
||
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.
Description
•