Closed
Bug 16213
Opened 25 years ago
Closed 20 years ago
Add throbber capabilities to minimized window (icon)
Categories
(SeaMonkey :: UI Design, enhancement, P3)
SeaMonkey
UI Design
Tracking
(Not tracked)
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
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Updated•25 years ago
|
Severity: normal → enhancement
Summary: Add throbber capabilities to taskbar icon → [RFE] Add throbber capabilities to taskbar icon
Updated•25 years ago
|
Assignee: don → german
Component: Browser-General → UE/UI
QA Contact: leger → elig
Comment 4•25 years ago
|
||
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>
Reporter | ||
Comment 6•25 years ago
|
||
Reporter | ||
Comment 7•25 years ago
|
||
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.
Reporter | ||
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
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?
Comment 12•25 years ago
|
||
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
Comment 13•25 years ago
|
||
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
Comment 14•25 years ago
|
||
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
Reporter | ||
Comment 15•25 years ago
|
||
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.)
Comment 16•25 years ago
|
||
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.
Reporter | ||
Comment 17•25 years ago
|
||
I can sorta see your point. How about making it only change when the window was
inactive?
Comment 18•25 years ago
|
||
That would make it look weird on window managers with hover-to-focus.
Reporter | ||
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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
Comment 21•25 years ago
|
||
Notlikely we will be able to get there but move to later milestone anyway. M20.
Target Milestone: M16 → M20
Comment 22•24 years ago
|
||
Since this is now a cross-platform bug, Bug #23094 should probably be closed as
a dup.
Comment 23•24 years ago
|
||
Right you are, Garth ...
Comment 24•24 years ago
|
||
*** Bug 23094 has been marked as a duplicate of this bug. ***
Comment 25•24 years ago
|
||
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
Comment 26•24 years ago
|
||
I propose reassigning this bug to ben, the mozilla UI owner, so he can add this
to his 'ongoing discussions bin'
Comment 27•24 years ago
|
||
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.
Comment 28•24 years ago
|
||
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.
Comment 29•24 years ago
|
||
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.
Comment 30•24 years ago
|
||
Comment 31•24 years ago
|
||
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.
Comment 32•24 years ago
|
||
See also bug 69885.
Comment 33•24 years ago
|
||
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
Updated•24 years ago
|
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
Reporter | ||
Comment 34•23 years ago
|
||
This is fixed in tabbed-dialog mode (bug 100706).
Comment 36•23 years ago
|
||
See also bug 109037, which would display site icons in the title bar, possibly
interfering with this use of the window icon.
Reporter | ||
Comment 37•23 years ago
|
||
The site icon should only be shown after the page has finished loading, as
happens with the tabs now.
Comment 38•23 years ago
|
||
I'd like to add that, at least in default installations, WindowMaker miniwindows
*only* appear when a window is minimized, AFAICT.
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
Comment 39•21 years ago
|
||
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
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Reporter | ||
Comment 40•20 years ago
|
||
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
You need to log in
before you can comment on or make changes to this bug.
Description
•