Closed Bug 79948 Opened 23 years ago Closed 23 years ago

Fix prefs dialog size

Categories

(SeaMonkey :: Preferences, defect)

defect
Not set
blocker

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugs, Assigned: bugs)

References

Details

(Keywords: regression)

Attachments

(1 file)

The preferences dialog size should be fixed at a smaller size (closer to 4.x), 
this size should be specified in ems and the dialog should be made non-
resizable (Preferences is a dialog, not a window).
Looks ok to me. r/sr=waterson, whichever helps.
I think the patch is ok, but this is going to cause a world of hurt. ;-) r=pchen
OS: Windows 2000 → All
Hardware: PC → All
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Blocks: 80304
I'm not sure we need to constrain the user like this.  Maybe a minimum
size, but ? why a maximum?  Some content doesn't fit in this area,
that's been an on-going problem, and resizing the window -> larger
is a workaround.  reopening for explaination.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Because (on Windows, at least) it shouldn't be resizable.  And sure, it's a 
good workaround -- too good.  What better impetus to get people to fix their 
crappy pref panes than to make it literally impossible to see all the options 
if they don't fit?  Not sure why Ben did it right before Netscape had its UI 
freeze, but that's really none of my concern...
*** Bug 80304 has been marked as a duplicate of this bug. ***
*** Bug 80333 has been marked as a duplicate of this bug. ***
No longer blocks: 80304
While it's nice to have a standard sized pref window, we need to figure out w/
UE's help how to move the other prefs that aren't getting seen (primarily LDAP
prefs) into the preferences window.  The timing is poor considering today is the
deadline for non-PDT controlled checkins.  

This will require reworking of LDAP prefs.
=>Jennifer needs time to rework the spec
=>Srilatha needs time to reimplement Prefs code
=>blocking of testing and usage of LDAP functionality (can't add/edit LDAP
directories)
=>possibility of regressions in the new LDAP prefs code

Was this checkin to resolve a blocker?  It's certainly blocking our testing.

I'm changing severity accordingly to "blocker".
Severity: normal → blocker
Keywords: regression
I'll start working at re-working the affected mail related dialogs.

Agree it would be nice to have more time for this since a lot of dialogs are 
affected.
I know this would be a separate bug, but what do folks think about removing the 
"Category" text from the top left and removing the Heading area and text from 
the top of the prefs dialogs?

"Category" shouldn't really be necessary and currently the heading label just 
repeats the text that is already selected in the list on the left.  This would 
give us a little more space.

Worth filing a separate bug about? 
Ironically, shrinking the category tree in the pref window made the panels
wider, and my examination of the panels showed only one or two that didn't fit
(and the overflow was small). 

Yes, we could probably remove the Category header. File another bug on me if you
like, triage it into .9.1 or .9.2 and it'll show up on my radar. 

This bug is being closed again as it has been fixed. The prefwindow is resizable
and of a fixed size. 
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Also, all panels that don't fit should get bugs. I believe there's already one
for the outstanding mail panel, and trudelle mentioned filing one on the LDAP
panel. 
bug # 80304 ( about LDAP panel) was marked as a dup of this one...
ben wrote:

> Yes, we could probably remove the Category header. File another bug on me if
> you like, triage it into .9.1 or .9.2 and it'll show up on my radar. 

jglick, i'd actually hold off on filing that bug, since bug 78261 suggests a use
for that header as means of navigating btwn the right-hand panel and the
category tree:

------- Additional Comments From Aaron Leventhal 2001-05-11 13:31 -------

I would just put an accesskey on "Category", so the user can press Alt+C to get
to that [right-hand panel] from the dialog.

o'course, that's currently blocked by bug 959... :-/
to keep myself sane, i've created a meta bug to track pref panels whose content
needs readjusting in order to fit: bug 80392. feel free to add bugs as blockers
to 80392. thx!
sairuh, I already filed the bug as 80394 (sorry). It can be marked invalid if 
folks agree. But I think it would be nice if the duplicate Header Label can be 
removed as well as "Category".  Is there another way to do the shortcuts? Like 
maybe Shift+Tab to switch between the list and the contents on the right?  
*** Bug 80450 has been marked as a duplicate of this bug. ***
*** Bug 80137 has been marked as a duplicate of this bug. ***
> Because (on Windows, at least) it shouldn't be resizable.

Rubbish. There are plenty of resizable dialog boxes in Windows and its applications.

> And sure, it's a
> good workaround -- too good.  What better impetus to get people to fix their
> crappy pref panes than to make it literally impossible to see all the options
> if they don't fit?

Translation: "We need to make life harder for our users in order to get our
developers to do the right thing."

That is a poor argument. The prefs dialog should be resizable, with a reasonable
preset minimum size.

Anyway, we've argued over this before. I solved the problem for myself by
switching to Linux, where my window manager makes everything resizable whether
Mozilla's developers approve or not.
> Rubbish. There are plenty of resizable dialog boxes in Windows and its 
> applications.

When the resizability was needed because the dialog's designers couldn't manage 
to make its contents fit?  Which ones are you referring to, specifically?

> Translation: "We need to make life harder for our users in order to get our
> developers to do the right thing."

Months away from Mozilla 1.0, there's really no danger in doing this, now is 
there?  Everything up until then is a beta version, with quirks far worse than 
this.

But the answer to your question is largely yes.  If developers won't abide by 
the rules, then maybe they will when they have no other choice.  In the time 
that people (developers of these panels included) spent whining about this 
tonight, they could have fixed every single problematic panel.  To prove this, 
Ben set out last night to do it -- and succeeded, even at upwards of 200% font 
size and Large Fonts on Windows.

What was the translation for the developers' apathy to take a couple extra 
minutes and make their panels fit in the first place?  "We don't care enough 
about our users to spend 3 more minutes, so let's throw in this cheap hack and 
call it a day"?

> I solved the problem for myself by switching to Linux, where my window 
> manager makes everything resizable whether Mozilla's developers approve or 
> not.

Cool.  On Windows, resizability is generally a characteristic of windows only, 
not dialogs.  An exception *may* be when being able to enlarge the window is 
extremely useful -- but not necessary -- for the user (e.g. the native 
filepicker), but this isn't even one of those cases.

> Which ones are you referring to, specifically?

Find in Files, File Open/Save.

These dialog boxes are not resizable because the designers were incompetent.
They are resizable because sometimes their fields contain arbitrarily large user
data. This is also true for the Mozilla prefs dialog (see, e.g., the Domains
fields of the Mail and Newsgroups | Send Format pane).

> Months away from Mozilla 1.0, there's really no danger in doing this, now is
> there?  Everything up until then is a beta version, with quirks far worse than
> this.

If this is your real argument, then you must file a bug to get this corrected
before Mozilla 1.0. But I guess it is just a feint.

> But the answer to your question is largely yes.  If developers won't abide by
> the rules, then maybe they will when they have no other choice.

So put in some checks at some stage other than the ultimate user experience.
Say, the prefs module owner. Note that developers using Linux and who happen to
use certain window manager settings will be entirely untouched by your attempt
to enforce "the rules".

I'm not going to apologise for the developers. Maybe they really are lazy and
inconsiderate. I just don't want users to carry the can.

> On Windows, resizability is generally a characteristic of windows only,
> not dialogs.

I suggest that that is not because of any well-thought-out usability concerns,
but because with standard Windows tools (i.e., Win32 DIALOG resources) it is
extraordinarily difficult to implement sensibly resizing dialogs.

In other widget sets that support resizing dialogs fairly naturally, such as Qt
and Motif, most or all dialogs are resizable.

I have not seen a rational argument for how resizable dialogs detract from
usability (providing a few basic requirements are met: sensible minimum/default
sizes, and unobtrusive resize widgetry).

> An exception *may* be when being able to enlarge the window is
> extremely useful -- but not necessary -- for the user (e.g. the native
> filepicker), but this isn't even one of those cases.

Whenever I type more text into a text widget than can be displayed in it, it
would be very useful to be able to resize the dialog box so I can see all the
data. This happens to me pretty often. It happens in the Mozilla prefs pane.
Since there's no real cost in usability for making the dialogs resizable, I get
a net usability gain by making these dialogs resizable.
As of 20010514 Windows build, the Preferences window is still not resizable!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Right -- it's not resizable -- that's why this bug is fixed (see original 
report).
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Keywords: mostfreq
"I get a net usability gain by making these dialogs resizable."

That may be true, but unfortunately there is cost associated with this. I'm sure 
the developers of the overflowing panels didn't check in panels that they saw 
overrunning in their own builds. They'd likely enlarged the dialog from previous 
usages and were seeing an exaggerated dialog size, and as a result designed 
their panels to fit that size. 

verify fixed
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: