155118 - Classic should have its own new mail alert popup icon

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, enhancement)

Description

[John Dobbins]

The Popup for new mail in classic uses the same icon as the Modern skin, and it
looks out of place among the Classic skin icons.

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

Confirming as an RFE, but see:

http://www.mozilla.org/mailnews/specs/mailnotify/

Under Open Issues Popup Alerts:

4. Visual design of alert and tray icons. "Get Messages" toolbar icon or
masthead icon for alert. 
Should tray icons be "Modern" or more generic? Stick with modern theme across
all themes or per theme
alert and tray icon? Marlon to decide. Width of alert can now be dynamic
(yeah!). Resize as necessary
 to fit width of user name.  3/18/02.

Comment 2

[John Dobbins]

Attachment: new-mail-alert.png

Adding Classic styled new-mail-alert.png

Comment 3

[John Dobbins]

As far as using a standard icon goes, I maintain the Mozdev theme page. Most of
the Theme Authors prefer being able to modify the graphics and we get complaints
about themes that leave part of the graphics the same as the Modern or Classic
themes.

Most users are either going to pick one theme and stick with it, or have two or
three favorites they switch between, so they will quickly become familiar with
each themes icons.

Comment 4

[jglick]

Alert popup and tray icon. The options include:

1. Theme specific
2. Always use Modern, since its the default theme
3. Use a more generic design, independent of any particular theme

Comment 5

[timeless]

jglick #2 is *not* an option for mozilla.

For the popup it should be skinable.

For the tray icon, i'd suggest generic. Although afaik all such art is under a 
licensing hold.

Comment 6

[John Dobbins]

Since the Pop up icon is located in the Chrome/messenger/icons directory it's
currently skinable and many third party themes are allready replacing it. All
this bug does is bring Classic into compliance with Modern and third party
themes by having a Pop up icon that matches the rest of the icons in the theme.

All a generic Pop up icon will accomplish is Mozilla will have two themes (not
counting third party themes) instead of one theme that has a Pop up icon that
dosen't match the other icons.

Does the icon attached to this bug convay the same meaning as the present icon?
Yes it does. Does leaving it skinable insure that a third party theme author
won't substitute an icon without a clear meaning? No, but this is true of ALL
skinable icons and a third party will cause a lot more problems with the
usibility of his theme by substituting a bad back button icon than a bad pop up
icon. If someone makes bad choices then people simply won't use that theme.

Anyway if the icon should be skinable is outside the scope of this bug. Right
now it is, and as long as it remains skinable Classic and Modern should have
icons that match the other elements in the Theme. If a decession is made to go
to a generic non skinable Icon, a Classic styled icon can be removed from
Classic's source just as easily as the present Modern style can be removed. If a
Generic icon is left skinable (in chrome/messenger) a Classic styled icon can be
replaced just as easily as the present Modern styled icon, and in the meantime
Classic will lose an element that currently sticks out like a sore thumb.

Comment 7

[Jesse Ruderman]

*** Bug 135714 has been marked as a duplicate of this bug. ***

Comment 8

[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 9

[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