Closed Bug 16213 Opened 25 years ago Closed 20 years ago

Add throbber capabilities to minimized window (icon)

Categories

(SeaMonkey :: UI Design, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 82130
Future

People

(Reporter: ian, Assigned: law)

References

Details

(Keywords: helpwanted, platform-parity, Whiteboard: [Win: 0%][Mac: 0%, depends on bug 36305][X: 0%] parity-opera)

Attachments

(5 files)

How about making the taskbar icon change depending on weather or not that window is downloading a file? IE has a similar feature but it doesn't work properly (surprise, surprise). In the next message I will attach two 16x16 icons Lemming www.lemnet.com
Attached file A temporary normal Mozilla icon (deleted) —
Severity: normal → enhancement
Summary: Add throbber capabilities to taskbar icon → [RFE] Add throbber capabilities to taskbar icon
marking RFE
Assignee: don → german
Component: Browser-General → UE/UI
QA Contact: leger → elig
Assigning to German for consideration.
I cannot see the attachment but I think it's a good idea as an enhancement if we have time. BTW when clicking the link I get a CGI file, when viewing that with a hex editor I see "Paint Shop Pro Image File". Please repost to this bug as GIF. <off topic> we should also change the window title in case of downloads to show the percentage number first, such that when the windows taskbar buttons get very small you can at least still see what percentage is done without having to mouseover. </off topic>
Target Milestone: M16
Generally like the idea although the means by which you achieve that as shown in your GIFs should -not- be looking like a disabled button, as windows that are busy are in fact enabled, not disabled and can be called into focus at any time. Showing them disabled is confusing. But the idea is good and like to leave this one the radar for past beta.
That is a good point, I originally inverted the colors but that didn't seem clear enough to me. Being disable might be OK, since most people won't watch a webpage downloading if they have multiple windows open.
Status: NEW → ASSIGNED
No, that is a miuse of the disabled appearance. Again since the windows *are* available they should not be clickable and have enabled appearance. I do like the idea though of indicating some sense of 'progress'/state for the windows not currently in sight.
Bug #23094 is related. It's basically the same thing, but for miniwindows in the WindowMaker window manager for Linux. Are they similar enough to be merged, or should they be kept separate?
Moving UE/UI component bugs over to new User Interface: Design Feedback component. UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (mpt@mailandnews.com). Matthew Thomas is now the QA owner for the User Interface: Design Feedback component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser should continue be QA assigned to elig@netscape.com.)
QA Contact: elig → mpt
German's `off-topic' comments are covered in two `Progress window' component bugs: bug 35046 (`[RFE] Show download progress (%) in title bar when minimized') and bug 36776 (`[RFE] Show download progress in window icon'). Browser window title bars (in fact, the title bars for any windows which are carrying out tasks with determinate progress) should probably use the same scheme as the progress window does -- but in all cases, it should only happen when the window is minimized (Windows) or window-shaded (MacOS). Marking All/All (and resummarizing) because this applies on all platforms, and pp because this would require different fixes on each platform.
Keywords: pp
OS: Windows 95 → All
Hardware: PC → All
Summary: [RFE] Add throbber capabilities to taskbar icon → [RFE] Add throbber capabilities to minimized window
Why should the icon only change when the window is minimized? I can only speak for windows, but I often have many windows active and maximized, all downloading webpages. This bug was intended to stop the constant flicking between the windows to see if one had download that I currently have. This bug could be complicated on MacOS. As I understand it, the tasks menu (in the top right, equiv of taskbar on windows) will only list one item per executable, making this impossible. Also, IIRC, there is no icon for the active app anywhere under MacOS, this would need a text version instead of the proposed graphical version. (If this was implemented, I imagine it would go along the lines of the following character being added to the front of the title bar: | / - \ As currently happens on some unix programs.)
The icon would only change when the window was minimized, because otherwise the icon would be constantly flickering between normal and throbbing mode during normal browsing. Such flickering in a normally stable part of the UI (the window border) would look like a bug. On MacOS, the proxy icon in the window title bar (bug 36305) would be used.
I can sorta see your point. How about making it only change when the window was inactive?
That would make it look weird on window managers with hover-to-focus.
Not sure how to resolve this, except have loads of code that leads to a what looks like a buggy implementation, or add yet another pref. As I explained above, making it minimized only would really defeat the purpose for me. Is the flickering really a big problem? You would have thought I would have had the same problem with the trobber in Mosaic, being the first throbber I had seen in what was previously a static panel. Yet I remember no problem. Also I do have a problem with WinAmp (scrolling title) or the download progress windows (changing percentage). I have mentioned this bug on mozillazine so hopefully some other people may have ideas.
I saw this bug on Mozillazine ;-) What I would do is have the progress all the time, but just a single line of e.g. blue pixels along the bottom of an otherwise static logo - a sort of very small progress bar. When it reached the far side, the doc is done. Moz might stick his tongue out at this point, or change colour. This way, you add the functionality but avoid excessive flickering. BTW, I second the point that said if it only works when the window is minimised it defeats the whole object of the exercise. I could definitely do with this feature. Gerv
Notlikely we will be able to get there but move to later milestone anyway. M20.
Target Milestone: M16 → M20
Since this is now a cross-platform bug, Bug #23094 should probably be closed as a dup.
Right you are, Garth ...
Blocks: 36776
Keywords: helpwanted
Whiteboard: [Win: 0%][Mac: 0%, depends on bug 36305][X: 0%]
*** Bug 23094 has been marked as a duplicate of this bug. ***
I agree with matthew here in that "it should only happen when the window is minimized (Windows) or window-shaded (MacOS)" to keep the UI 'stable' and to avoid redundant redundant progress feedback (the status bar of an open window in proximity to the windows 98 taskbar or Linux taskbar). Marking future to keep the discussion open.
Target Milestone: M20 → Future
Assignee: german → ben
Status: ASSIGNED → NEW
I propose reassigning this bug to ben, the mozilla UI owner, so he can add this to his 'ongoing discussions bin'
Making this feature only work for minimized windows would cause the icon to change to the "loading" state pretty much only when you minimize a window that's loading something. Since this is when my attention is drawn to the icon (because of the Windows animation effect for minimizing a window), it would make the UI look unstable. Making it only work for minimized windows would also require me to take an extra action to tell the browser "notify me when this new window finishes loading", which would slow me down in opening new windows to the point that the feature wouldn't be useful anymore, not to mention making the feature hard to discover. The same problem applies to changing the icon for all but the active window: the icon will change from "normal" to "loading" when I click on another taskbar icon, which is likely to be when I'm looking at the taskbar. I'm much less likely to be distracted by a small change in the icon if I'm clicking a normal link on a webpage than if I'm shuffling windows around. I don't understand how having an extra progress bar or "finished" indicator would make the UI seem less stable (mpt 2000-04-28 10:06). We already have plenty of UI elements that change appearance when the page finishes loading, and I think that's fine, because it lets me read the first part of a page and still notice when a page finishes loading. Most other apps don't need to use their icons to indicate when they're finished loading something because they don't often load information while they're in the background.
Internet Explorer for Windows flashes the taskbar button when a page has finished loading, except when the window is at the front (where you have quite enough notification already). Why don't we do that instead? It would be both more obvious and less weird than using different icons for ready/busy states.
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.
Attached image false color progress from net+ (deleted) —
I've seen IE 5.5's taskbar buttons flashing between grey-darkblue occasionally, but it doesn't seem to do that whenever a page loads in an inactive window. The only way I can make that happen in IE is to open several instances of IE to my homepage at the same time. Anyway, that effect is designed to get the user's attention, which isn't what we need here. We need a subtle effect that isn't too distracting when you're not looking at it, but indicates which which windows are ready for you to click on (so you don't waste time switching between a bunch of windows that haven't loaded yet). I'd prefer if it didn't involve flashing or throbbing. I take back the second paragraph of my last comment, provided that the icon changes fairly quickly when I switch windows. I might not even see a subtle icon change when I'm switching between windows because of the large change to the taskbar icon when I switch windows (depressed vs un-depressed), and in that case always showing the "finished" icon for the active window would be ok.
See also bug 69885.
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Summary: [RFE] Add throbber capabilities to minimized window → [RFE] Add throbber capabilities to minimized window (icon)
Whiteboard: [Win: 0%][Mac: 0%, depends on bug 36305][X: 0%] → [Win: 0%][Mac: 0%, depends on bug 36305][X: 0%] opera-parity
This is fixed in tabbed-dialog mode (bug 100706).
Window icon related, -> Bill Law
Assignee: ben → law
See also bug 109037, which would display site icons in the title bar, possibly interfering with this use of the window icon.
The site icon should only be shown after the page has finished loading, as happens with the tabs now.
I'd like to add that, at least in default installations, WindowMaker miniwindows *only* appear when a window is minimized, AFAICT.
No longer blocks: 36776
Summary: [RFE] Add throbber capabilities to minimized window (icon) → Add throbber capabilities to minimized window (icon)
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → paw
Fixing status whiteboard to be consistant with other parity-opera bugs for easier searches. Sorry for the bugspam.
Whiteboard: [Win: 0%][Mac: 0%, depends on bug 36305][X: 0%] opera-parity → [Win: 0%][Mac: 0%, depends on bug 36305][X: 0%] parity-opera
Product: Core → Mozilla Application Suite
Resolving as duplicate of "favicons on the taskbar" - when that bug is fixed, this bug will be redundant. Plus there haven't been any real comments here for four years. *** This bug has been marked as a duplicate of 82130 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: