Remove the "Category" text from the top left and remove the Heading Label from the top of the prefs dialogs. "Category" shouldn't really be necessary, since the lists of available items should be self explanatory. 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 in the Prefs dialog. Spin of of bug 79948.

depending on the outcome of bug 78261, this might become invalid.

jglick, I agree about "Category", but not about the right-side header. Eudora used to have a prefs dialog like this (i.e. list on the left, changing prefs on the right), and I don't know how many times I've seen people get confused by it. Novices, especially, couldn't understand the left side selection controlled the right-side contents. Having the header there will make that a little plainer, I think.

I'd be reluctant to get rid of the panel headings -- especially since its possible for the name of the current panel to be scrolled out of sight in the category list. Getting rid of the `Category:' would improve the aesthetics of the dialog, but I'd want to test it with some novice users first.

I'd like to keep "Category" there. Once bug 959 is fixed, we can make C the accesskey, so users can press Alt+C to navigate in that list, from anywhere in this dialog.

Would it be possible to at least shrink the vertical size the Heading area?

Wow, are you *that* desperate for pixels? :-) ... Anyway, filed bug 81581 to do that in Mac Classic. This is the point where I hope like mad no-one notices that what I said in this bug is the direct opposite of what I said in my 2000-08-28 comment in bug 45886.

Yes, i'm that desperate for pixels. :-) But in addition to pixels, I think the header takes up to much space relative to the rest of the dialog.

nav triage team: Not a beta stopper, and we're not desperate for pixels. ;-) Marking nsbeta1-, p4, mozilla1.0

We may just be desperate for pixels. The category idea could provide a fix for a number of my other 0.9.3 bugs in one fell swoop. I've heard competing arguments from mpt on this in this and the purple-sparkle bug (::gigglez::). What's your feeling today, Matthew?

We can also set the title of the window on page change Prefererences - Helper Applications

As the saying goes, the fact that I have changed my mind does not alter the fact that I am right. :-) My excuse is that in bug 45886 I was on a get-rid-of-the-purple-sparkle jihad, but that particular manifestation is now covered by bug 81581. I really really think you shouldn't get rid of the panel header. Opera and Internet Explorer for Mac OS have a similar prefs layout and don't have such a header. But in Opera, you can't scroll the selected panel out of sight in the category listbox, because the length of the category list is less than the length of the listbox. And in both Opera and IE, many panels have a groupbox, named the same as or similar to the panel itself, encompassing some or all of the panel anyway (which generally looks pretty crappy). And on a minor forward compatibility note, the right end of the panel header was where I was expecting to put an unobtrusive popup menu for handling pref zones (for handling site-specific JavaScript prefs, Security prefs, Fonts prefs, Colors prefs ...) I also envision a matching stripe on the bottom of each panel, containing a `Reset to Defaults' button and/or a `Use Internet control panel settings' checkbox controlling that particular panel. As for the `Category:' header, I'd be quite happy to see that go. But I think it could only go if the panel header stayed, otherwise novice users would be *completely* without visual cues as to how the category listbox and the other controls in the prefs dialog interacted. > We can also set the title of the window on page change > Prefererences - Helper Applications Let's not. Firstly, `Foo - Bar' window titles are a Windows-ism which should not be allowed to breed elsewhere. (Yes, I know they're present elsewhere in Mozilla, especially in mail/news, but that needs to be fixed too.) Secondly, window titles are sometimes dynamic (message composition in Mozilla, Get Info in the Finder), but I've never seen a dialog title which is. and thirdly, making the dialog title dynamic would be rather disconcerting, especially given the frequency with which prefs dialog users need to switch categories. (Remember, titles are centered on Mac OS and on many Unix wm configurations, so `Preferences' would be jumping about all over the place.) As always, if you're short of pixels I'm always ready to volunteer lists of prefs which you could get rid of ...

OK, I'll experiment with making them smaller.

nav triage team: This is not a mozilla0.9.3 stopper. Moving back out to mozilla1.0 If we want to do something with the prefs window, how about adding a few more pixels to the window itself?

Very funny.

Joe, do you have any objection if I try making the headers thinner in Modern?

.99/P4

Patch per mpt's guidance. Removes the "Category" header and makes the header in the pref panel itself a little smaller in classic (also makes it follow system colors reasonably on the Mac, which is bug 81581). Screenshot of what this looks like on Linux coming up.

padding not 2px 4px but 3px 6px

Comment on attachment 83348 [details] [diff] [review] updated patch (as requested by mpt) r=andreww

Resummarizing, marking as blocker of bug 81581, looking for sr.

If I'm seeing the screenshot correctly, it looks like the black border around the edges of the category name has been removed. While this is just a nitpick, I'd say the black border looks a tad bit more professional than without.

I really don't think you want a background-color of ThreeDShadow in the mac classic version -- that's not a color meant as a background color. (I also kinda liked the indentation and the thinkness of the heading.)

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

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

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

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

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

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

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

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

We won't do this.