93051 - "Appearance" preferences panel seems unfinished

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[Henrik Gemal]

The "Appearance" dialog seems unfinished:
- "Show Toolstips" just stand in the middle og nowhere. I have no clue what 
kind of tooltips we're talking about
- "Choose a language" text should have a line/box around it.

build 20010731

Comment 1

[Boris Zbarsky [:bzbarsky]]

over to UI design.  This is almost certainly a dup.

Comment 2

[Gervase Markham [:gerv]]

This prefs panel needs a spanking. There's extra whitespace all over the place,
and the language section needs a rethink. Whoever does it will probably want to
consult a UI designer, however briefly.

Gerv

Comment 3

[Henrik Gemal]

I cant find the dupe. Is there a "remake" Appearance bug?

Comment 4

[Sören 'Chucker' Kuklau (gone)]

Now that the language section was removed, we have even more free space.

Perhaps we should only have an introductory text in Appearance, like it is in
Privacy & Security, and have extra panels "Startup" and "Other"?

Comment 5

[Matthew T (active 1999-2002)]

Preferences category branches should not exist as separate panels, as the 
absurdity of the Privacy & Security branch panel demonstrates. I suck at 
designing UI for things which shouldn't exist (e.g. I keep away from tabbrowser 
bugs), so I have no idea how to clean up this panel. I can, however, tell you 
how to get rid of it.
(1) Make Navigator, mail/news, Composer, etc separate programs dependent on an
    XPCOM library, so that `When Mozilla starts up, open' makes as much sense
    as `When glibc starts up, open'.
(2) Make `Show Tooltips'/`Hide Tooltips' an item in the `Help' menu, rather
    than a checkbox in the preferences.
(3) Fix the bugs in the display of site icons, and get rid of that pref (not
    necessarily in that order).

--> Preferences

Comment 6

[Samir Gehani]

Marlon,
Where should the tooltips pref go?  

Comment 7

[beyerg]

In "Apperance" portion, no options for buttons: Picrue only, Text only, Both
Picture and Text.

NS 4 has this capability

Comment 8

[Jason Bassford]

> Where should the tooltips pref go?  

Wherever it goes, it makes sense that "Show Web Site Icons" goes with it.

> In "Apperance" portion, no options for buttons

bug 22056

Personally, I think Tooltips and Show Web Site Icons should stay where they are,
and the results of bug 22056 should be added when that's done.

Further, if anything doesn't belong in Appearance it's starting Navigator or
Composer.  That pref would be more appropriate in a Startup section - as implied
in comment 4.

Comment 9

[Sören 'Chucker' Kuklau (gone)]

Re: Additional Comment #5 From Matthew Thomas (mpt)  2002-02-28 19:12 -------
> Preferences category branches should not exist as separate panels,

What should clicking on a category branch do? Nothing (E.g., leave the previous
panel open)? Open the first panel in that category (I've seen that behaviour in
several apps... ugh)? Perhaps a random one.

Comment 10

[Robert Kaiser]

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 11

[Robert Kaiser]

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 12

[Robert Kaiser]

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 13

[Robert Kaiser]

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 14

[Robert Kaiser]

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 15

[Robert Kaiser]

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 16

[Robert Kaiser]

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 17

[Philip Chee]

Should be fixed by the great <prefwindow> rewrite.