128959 - Add icons to components in "Window" menu

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[jag (Peter Annema)]

See attachment for mockup (need better icons!).

Comment 1

[jag (Peter Annema)]

Attachment: mockup

Comment 2

[timeless]

i suppose this would be useful for me because then i could use it for my 
floating component bar.  the thing is, that if we're going to do this, then imo 
the component bar and the tasks menu should share their data and just use 
css+xbl to specify display (I have code that does this).

Comment 3

[Alfred Kayser]

There are allready icons available in the current component bar?
Why not use those? 

Comment 4

[jag (Peter Annema)]

That's the ones I'm using in the mockup. The problem is that they'll be
stretched and/or compressed, since they're not in 16x16 but 23x14 or 12x12 or
..., which we don't support in menu items (and we shouldn't, for aesthetical and
usability reasons).

Comment 5

[jglick]

I like it. :-)

Comment 6

[jag (Peter Annema)]

Attachment: Add icons to the tasks menu using place holder gifs for now (proper icons will be created and checked in)

Comment 7

[Brian Ryner (not reading)]

Comment on attachment 76991 [details] [diff] [review]
Add icons to the tasks menu using place holder gifs for now (proper icons will be created and checked in)

r=bryner

Comment 8

[Joe Hewitt (gone)]

Comment on attachment 76991 [details] [diff] [review]
Add icons to the tasks menu using place holder gifs for now (proper icons will be created and checked in)

sr=hewitt

Comment 9

[Blake Ross]

What is the rationale behind doing this?  I can't see how it improves component
discoverability, since most of our users are literate.  The only effect it seems
to have, besides being ugly, is being distracting.  The lack of space between
the icon and the text makes the menuitem more difficult to read, compared with
apps like Word (especially XP) which have plenty of spacing.

Comment 10

[jag (Peter Annema)]

The rationale behind this (but correct me if I got this wrong, Marlon), is to
give the user a consistent item of recognition for apps within the suite by
using the same icon wherever we offer a way to launch that app. So you get e.g.
the mail icon in the taskbar, in the tasks menu and on the desktop so that an
user will (hopefully) discover that using these three things all give the same
result, namely launching the mail app.

The only right way to add spacing here is to add it to all menus and menuitems.
Should we do this?

Comment 11

[Jaime Rodriguez, Jr.]

adt1.0.0+ approval for checkin, pending detailed unit testing on all platforms
and r/sr=.

Comment 12

[Asa Dotzler [:asa]]

Comment on attachment 76991 [details] [diff] [review]
Add icons to the tasks menu using place holder gifs for now (proper icons will be created and checked in)

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 13

[:deanis74]

"The only right way to add spacing here is to add it to all menus and menuitems.
Should we do this?"

Well, if we ever want to put icons in other places, then yes.

Comment 14

[Peter Henderson]

No ChatZilla icon? But the rest look great so far!

I must not be "a sufficiently empowered user." How about "Add icons to
components in Window menu" (Tasks is gone...)

Comment 15

[jag (Peter Annema)]

Patch checked in. I'll ping rginda about the chatzilla part.

Comment 16

[:deanis74]

Bug 135435 is for the chatzilla icon.

Comment 17

[:deanis74]

Wow, I'm making a mess of things today.  I meant bug 135455.

Comment 18

[Jesse Ruderman]

I agree with Blake, these icons are distracting and not useful.

Comment 19

[[e-mail]]

1. Why all the classes? You only need menuitem-iconic; hang the styles from ids.
   Mixing menuitem-iconic and menu-iconic definitely looks wrong.
#tasksMenuEditor {
  list-style-image: url("chrome://communicator/skin/taskbar/composer-16.gif");
}
2. Why not use the icons that the Windows builds use? Oh wait, there aren't any.
   The idea is that if someone installs new icons they'll stay in sync.
3. In which case, use src=, because those icons aren't in skin:
  <menuitem id="tasksMenuEditor" class="menuitem-iconic" ...
src="resource:/chrome/icons/default/editorWindow.ico"/>

Comment 20

[jag (Peter Annema)]

Eeek, how'd those "menu-iconic"s end up in there? And go undetected. Tsk tsk.
I'll try and get a fix for this in.

We're using (or will be using) icons that are similar looking to the ones in the
component toolbar, which are part of the skin. Also, if you take a look at the
navigator icon in the modern skin, you'll see it differs from the one in the
classic skin.

I thought about using IDs, but classes are more flexible in that this will allow
someone else to put this class on their element and get this same icon.

Comment 21

[sairuh (rarely reading bugmail)]

vrfy'd fixed with comm 2002.04.09 bits on linux rh7.2 and win2k.

these icons do *not* appear on mac (10.1.3) --which is by design, yes? (since we
use native toplevel menus.)

Comment 22

[jag (Peter Annema)]

Correct, until someone gets icons in native mac menus working (again?). There's
a bug on it somewhere.

Comment 23

[:deanis74]

I think icons in Mac menus may be bug 46177.