124535 - Download progress window is too large [small screen]

Status: RESOLVED EXPIRED

(SeaMonkey :: UI Design, defect)

Description

[Martyr]

This is a real issue on laptops, especially the clamshell iBooks, generally any
laptop with a 14" screen or less. Screen real estate is at a premium here, and
the large download progress dialog boxes take up too much room.  

Steps to reproduce:
1) Download a file.
2) The resulting progress dialog box cannot be resized. 

Suggestions: Can't use double-click because it is a dialog box (not a window),
and resizing a d ialog box violates gui standards. How about just making it
smaller to begin with or allowing the size of the box to be tweakable or skinable?

Comment 1

[Matthias Versen [:Matti]]

download window -> File Handling 

I dunno if this bug is valid !
Why not minimize the window if you want more room ?
(we have an RFE about the download progress % in the title bar)

Comment 2

[Boris Zbarsky [:bzbarsky]]

It's a dialog.  You can't minimize dialogs on MacOS.  That's what the "can't use
double-click" part refers to, correct?

mpt? thoughts?

Comment 3

[Martyr]

Boris, you are correct. You CANNOT minimize or resize the dialog box on MacOS
9.x. On Windows, you can minimize. Can you do that on Linux? I don't want to
reccomend violating the Apple Human Interface guidelines (by making the dialogs
into windows), so shrinking their size seems to be the best thing to do.

Comment 4

[Boris Zbarsky [:bzbarsky]]

You can minimize it on Linux, in most windomanagers....

I'll try to catch mpt (the UI Design default assignee) on IRC and ask him his
opinion.  He seems to not be reading bugzilla at the moment.

Comment 5

[Matthew T (active 1999-2002)]

Unfortunately progress windows aren't implemented in XP Toolkit, so we fake 
them by using dialogs instead. If this bug was about progess windows being 
unminimizable, it would be a duplicate of bug 76110. However, it's not about 
that; it's about the progress windows being too large. That should hopefully be 
fixed with the implementation of the download manager, which should use 
document windows (not progress windows) to show information about selected 
downloads. See <http://mozilla.org/projects/ui/navigator/downloads/#info>.

[De-diagloging summary]

Comment 6

[Martyr]

Ok, thanks Matthew. Resolving that bug will address the concerns I raised here
-- multiple ways to skin the cat. However, 76110 is still marked future so it
doesn't look like this is to be fixed soon. We can close this one and increase
the priority of that one or shrink the size as mainly an aesthetics function.
It's that the default size does not work well with laptops...

Comment 7

[sairuh (rarely reading bugmail)]

could you pls attach a screenshot of what you're seeing? thx!

Comment 8

[Martyr]

Attachment: Relative size of dialog box to whole screen size on laptop.

Warning...120k.

Comment 9

[sairuh (rarely reading bugmail)]

thanks, mtulloch! yeah, taking up nearly 25%of your screen realestate...

another question, what is the resolution setting you have? or, moreover, d'you
experience this after increasing the resolution (if you're even able to)?

Comment 10

[Martyr]

With the clamshell ibooks, max res. is 800x600...the screen size is I believe 13".

Comment 11

[Bill Law]

Next release, maybe.

Comment 12

[RogerWilco]

This is a better statement of what I meant in Bug #150744. (See also, Bug
#76110.) I use laptops most of the time, ranging from the sub-sized Powerbook
2400c (800x600) to the G3 2000 Pismo (1024x768). The current box layout is not
helpful to laptop users. This box can be made smaller by rearranging its text to
eliminate the present huge amount of wasted space in it. Too bad the box
apparently cannot be given a "minimize" widget to collapse it to the size of its
title bar if desired.  This is more than an aesthetics issue, IMO, and should be
addressed sooner than later to benefit us Mac users.

Comment 13

[Martyr]

I'm satisfied with the Download manager that's present in the latest builds
(1.2beta, Mac OS 9.x). That essentially fixes the problem below. What do you
think, RogerW? I'm in favor of marking it "Fixed" or probably better "WorksForMe."

Comment 14

[Boris Zbarsky [:bzbarsky]]

Except the old download window is still and option, and a lot of people still
use it... 

Of course if people don't care whether it's fixed...

Comment 15

[Simon Paquet [:sipaq]]

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".

Comment 16

[Martyr]

Retargeted. It's a dialog in MacOS for laptops problem, regardless of whether
it's 9.x or OS X. The problem of wasted space and taking up too much screen real
estate remains. 

Comment 17

[Robert Kaiser]

MASS-CHANGE:
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 18

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420