99380 - (docicons) Different shell icons to identify each associated file type

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, enhancement, P3)

Description

[TucsonTester2]

Build: 2001090303

There is no difference in the icon that is displayed for graphics or html
documents.  When there are many files in a folder this makes it more difficult
to find a specific file or file type.

I believe that there should be a difference between the icon displayed for html
documents and graphics, maybe even different icons for types of images.

Comment 1

[TucsonTester2]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

Reporter, what OS are you using?

Comment 3

[TucsonTester2]

I am using Win 98 SE

Comment 4

[Doron Rosenberg (IBM)]

themes?

Comment 5

[Asa Dotzler [:asa]]

This is already reported (I'm fairly sure). Please query Bugzilla before
reporting bugs to see if your bug is already known.

Comment 6

[Asa Dotzler [:asa]]

->XPApps

Comment 7

[Skewer]

RFE, confirming.

This would be a nice feature. Bug 73712 is related, but different (icons for
each type of window).

Comment 8

[Paul Chen]

->law

Comment 9

[Peter Trudelle]

->marlon

Comment 10

[Luke Morey]

If you're looking for the earlier bug...

This bug is really a dup of bug 27746.  But that was closed incorrectly as a dup
of bug 73712.  (As Skewer points out in comment 7 above, they're different bugs:
icons for different windows vs icons for different filetypes / URLs.)

Which one should stay open?  And does the dup reference from bug 27746 to bug
73712 need fixing?

Comment 11

[Asa Dotzler [:asa]]

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

Comment 12

[Skewer]

Here's a bit of info from bug 27746 (which should probably be left alone, since
it deals with two separate issues):

We should include icons for all of these file types. IMO, we should also have a
"catch-all" icon to avoid having files with the same icon as mozilla.exe or
Windows' default page icon. I'm going to put files that should use the same icon
on the same line. I do think each graphic format needs its own icon--nothing is
more annoying than being unable to tell a .gif from a .jpg.

.html, .shtml, .phtml, .xhtml...
.js, .dtd
.css
.http, .https, .url
.gif
.jpg, .jpeg, .jpe
.png
.mng
.svg
.bmp (not as important)
.ico (not as important)
.xml
.xul (not as important)

It was suggested that the name of the file format be written as small letters in
the icon... I personally think it would be better to avoid this and use a more
noticeable and symbolic distinction (e.g. WinXP uses a photograph icon for JPEG,
a paintbrush for BMP, and geometric shapes for GIF files, IIRC).

We could use some artistic talent to put these icons together. Also, as
mentioned in bug 27746, we need to support many different icon sizes. Each icon
should be provided in 16x16 and 32x32 formats (maybe 48x48 and 64x64), in 16
colors. To be nice to Windows XP users we might also include some stylish
true-color icons. Icons should be designed in Windows' native .ico format, since
that's the only format Windows can use for file associations.

Comment 13

[timeless]

Attachment: current version of url

Actually, icons should be designed as dPDF or PNGs with full alpha for use on
macosx.  They can then be degraded to .ico for windows and other formats for
other os's.

Note that there is absolutely no reason for us to take over .ico or .bmp.  We
don't ask to take over .txt.

(GIFs should be ok in general although they won't work for high color
requirements.)

Comment 14

[Robert Wall]

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

Comment 15

[Skewer]

I'll volunteer to do the ICOs if we get good PNG icons. However, try to make 'em
in these formats:

16x16
32x32
48x48

I think XP has an alpha layer on its new ICO format, BTW.

Comment 16

[Matthias Versen [:Matti]]

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

Comment 17

[Matthias Versen [:Matti]]

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

Comment 18

[timeless]

kerz is going to drive this for windows. we'll make more bugs for other
platforms as necessary.

Comment 19

[Jason Kersey]

taking.  Hopefully will get this fixed for 1.l final or 1.2 alpha.  Desktop
icons are going into 1.1 beta.  Mac and linux icons will all go in together in
their respective bugs linked off of bug 73712.

Comment 20

[Skewer]

The icons at <http://grayrest.com/moz/resources/icons.shtml> have been
implemented in bug 73712 for the navigator window icons. However, I dislike the
file-type icons that are provided at this URL, even though I think it would be a
good idea to follow the blue/orange design that has already been used for the
windows. Identifying the file types with miniature words is not terribly
legible, especially on blurry monitors or high resolutions.

Comment 21

[Skewer]

Attachment: Sample JPEG icon

For example, I would use something like this for JPEG images. Since JPEGs are
usually used for photos, a photograph-type picture is used to represent it. GIF
and PNG should be represented by something plainer, like shapes. HTML files
should have lines of text and an image or two, and XML should have a bracket.
This trend should be consistent for each format; nothing should ever use tiny
words. Note that this system is similar to the behavior of Windows XP.

Comment 22

[Matthias Versen [:Matti]]

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

Comment 23

[Malcolm Scott]

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

Comment 24

[Todd]

Hi All,

   I just installed 1.1.0.2002082611 for w2k. Cool new icon.
Is it time to close this report as "resolved"?

--Tony

Comment 25

[timeless]

no. this is for icons for *documents*. A window is *not* a document. We do not
yet have icons for documents.

Comment 26

[Alex Hosking]

Ill have a go at fixing this can any one tell me where the existing icons are
kept as i may need them for this

Comment 27

[Malcolm Scott]

Alex Hosking: icons are currently installed in Chrome\Icons\Default under your
Mozilla installation directory.

Comment 28

[Brant Gurganus]

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.

Comment 29

[Matthias Versen [:Matti]]

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

Comment 30

[Skewer]

Progress on this bug has been disappointing.

I've been thinking of putting together a design spec for Windows based on my
experience with the various flavors (95/98, 2000/ME, XP) and the way they handle
icons. After this is put together we might have some contributions for icon
designs, which is really all that is necessary to fix this bug except some minor
code changes.

Just a hint of what will be in this design spec:

Icons *must* be available in 48x48 size for Win2000, ME, and XP.
Icons *must* be more than 16-color because it's too boring.
Icons *must* be available in 32x32 and 16x16 because Windows does a very poor
job of scaling them.

etc...

Comment 31

[Michael Newton]

I think the priority of this bug should be changed; allowing users to easily
access files is not what I would call a "nice to have" feature.  Now that
Firebird is becoming the main focus, I'm guessing the "this is NOT for end
users" attitude is finally disappearing?

In the meantime, if nobody is going to make any progress on this bug, could we
at least use the icons from NN4?  The HTML icon does have an 'N' on it and would
need some fixing, but the image icons are very generic looking.

Comment 32

[Alex Hosking]

Agreed, And I'm supprised it aint been fixed since I have seen a few icon sets

Comment 33

[Matthias Versen [:Matti]]

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

Comment 34

[Robert Accettura [:raccettura]]

Comment #31 makes a lot of sense.  This is part of polishing an App.  

Right on the homepage it reads: "What this means for the Mozilla browser and our
other products and technologies: more innovation from the open source
developers, and a *greater focus on end users*."

End users need polish.  A sense of consistancy, completion, and attention to
detail.  Something Firebird/Thunderbird apparantly do pretty well already.  They
are beautifully themed (or becoming themed), light, fast, well thought out...

But still lack proper icons.  I would suggest this be a blocker for an official
Firebird/Thunderbird release.  Lets make this "1.0" something to shock even the
Mozilla doubters.

Perhaps it would be good to contact the IconFactory
(http://www.iconfactory.com/) and see if they would be willing to donate some
icons for the project?  The worst they could do is say no.  They already did
Windows XP, Netscape 6, Office v.X, Toast, and other products....

Would do an amazing job I'm sure.  Their icons are amazing quality and
creativity.  In OS X they are just outstanding.

I'm a fan if you haven't noticed.

Comment 35

[Jez]

Attachment: Jez's proposed icon for use with Mozilla-associated *document* filetypes

Comment 36

[Jez]

I've attached an .ico file containing icons I designed for use with *document*
filetypes associated with Mozilla.  I'm aware that it can deal with stuff other
than images, but I happen to use another program to deal with them.

As for the person who said that there's nothing worse than not being able to
tell a GIF from a JPEG, I can tell them apart and have the same icon for nearly
every image file.  How?  I have my shell set to show me file extensions. 
Seperate icons for different image types would bug me.

Anyhow, the icon I submitted would be intended to be associated only with
document filetypes dealt with by Mozilla, and hence it's a kind of piece of
paper with the dinosaur head on it.  I've associated it with some relevant
filetypes on my machine (eg. HTM, HTML, XML) and frankly think it looks pretty
cool :-)  The .ico contains icons that are 16x16, 32x32 and 48x48 pixels in
size, and there are 16 color and True color versions of each.  There's no point
in including 256 color versions, because Windows doesn't differentiate between
them and true color (dunno why).

Sorry it's only a .ico, I don't have the tools to create anything more advanced.
 Could you possibly make this the default icon for document-based filetypes that
Mozilla supports, when Mozilla is associated with them?  I like them better than
the mozilla.exe icon because it differentiates documents from Mozilla itself.

Comment 37

[Skewer]

  I've attached an .ico file containing icons I designed for use with *document*
  filetypes associated with Mozilla.  I'm aware that it can deal with stuff
  other than images, but I happen to use another program to deal with them.

I like this icon! (Coming from a WinXP user of course; this icon would be
somewhat inappropriate in any other OS.) I will say though, it doesn't look like
you put any effort into making the 16 color icons... not horrible.

  As for the person who said that there's nothing worse than not being able to
  tell a GIF from a JPEG, I can tell them apart and have the same icon for
  nearly every image file.  How?  I have my shell set to show me file
  extensions. Seperate icons for different image types would bug me.

That's a good workaround, but the proper way is for file extensions to be hidden
from the end user in the Windows environment (at least since 98). IE4 associated
itself with GIF and JPEG and used green for GIF and red for JPEG; Windows XP
uses a shapes icon, a sunset photo, and a forest photo to distinguish the
formats. I forget which icon goes to which format, but I currently have sunset
for JPEG (it's a photo and red), forest for PNG (it's a photo and not red), and
shapes for GIF (GIF is only useful for that type of basic image). Good file
association is file association which allows you to know the file's extension
without actually seeing the extension. Just as I can tell a Zip by the WinZip
icon, an XML by IE's "<world>" icon (this is one of my favorite most intuitive
icons), and a text file by the notepad icon, I should be able to recognize
whether an image is a GIF, JPEG, or PNG just by its icon. One could get used to
having extensions on in a disappointing environment where all the formats have
the same icon (as Paint Shop Pro does). Photoshop uses tiny text to distinguish
the formats, which is also very poor design. (Of course I won't make a large
fuss about what Mozilla does with image format icons, because I'm never going to
assign those formats to Mozilla; I'll assign them to a much more capable image
editing program. Right now I associate them with PSP and I've overridden the PSP
icon with the WinXP default icons as described above.)

Anyway, I think this icon just submitted would be good enough for HTML
documents. I would use it for files ending in .HTML, .SHTML, .PHTML, .XHTML, and
anything else that's just a different version of HTML. However we need something
more intuitive for CSS and XML. (Wait, do we associate with CSS? Seems like we
should if we have a Composer...) I think for XML we should do something similar
to the MSIE icon for XML, and for CSS something similar to the WinXP .INI icon
(which is what I currently use). The red color is a good theme to stick with but
I think both the bent-corner page and the lizard are bad things to get too
attached to. It's more important that we have icons that represent their file
format well.

Comment 38

[Jez]

> I like this icon! (Coming from a WinXP user of course; this icon would be
> somewhat inappropriate in any other OS.) I will say though, it doesn't look
> like you put any effort into making the 16 color icons... not horrible.

Huh?  That didn't make sense... do you like the 16 color icons, or not?  I spent
some time making them look acceptable, I think they're OK, but frankly, what
would look *good* in 16 color? ;-)

  As for the person who said that there's nothing worse than not being able to
  tell a GIF from a JPEG, I can tell them apart and have the same icon for
  nearly every image file.  How?  I have my shell set to show me file
  extensions. Seperate icons for different image types would bug me.

> That's a good workaround, but the proper way is for file extensions to be
> hidden from the end user in the Windows environment (at least since 98). IE4
> associated itself with GIF and JPEG and used green for GIF and red for JPEG;
> Windows XP uses a shapes icon, a sunset photo, and a forest photo to
> distinguish the formats.

OK, I have a totally different way of identifying file types to you.  I like the
icon to identify what *program* is going to open the file, and I identify the
actual filetype by extension.  When I'm using a system with file extensions
disabled, I go slowly mad.  I want to see the FULL filename, damnit!

Besides, with image files, it's usually quite obvious what filetype they are by
context, eg. website images are likely to be GIF, and family photos are likely
to be jpeg.  But when you're opening the things, it doesn't really matter what
format they are, as long as your image handling program supports them; what
matters to me is the program that will open them.

To that end, I like every file associated with a particular program to have *the
same* icon.  Therefore I think XML, and every other filetype Mozilla deals with,
should have this icon associated.  If you really need to have different icons
for different filetypes, manually associate them yourself.

> I think both the bent-corner page and the lizard are bad things to get too
> attached to. It's more important that we have icons that represent their file
> format well.

I disagree.  When I see that XML icon that IE uses (I must admit I very rarely
work with XML files so I haven't seen it before) it makes me think a non-IE
program will open it.  I think I'd manually change that to the standard
'IE-handled file' icon.

Comment 39

[Michael Newton]

Personally, I do use file extensions, and I do not use FB/Moz to view images. 
In fact, I don't even think we should associate with images, but that's another
matter.  The fact is, in Windows, if you are looking at a folder with hundreds
of icons in list view, files tend to all look the same after a while, extensions
or not.
And of course, comment 37 is correct: MS wants to appear just like a Mac desktop
with no file extensions.  Software products that are being made for an OS should
try to fit into the 'look and feel' of that OS.  That brings to mind another
argument for icons, what about the Mac?

See, there are advantages to corporate giants like MS, they probably pay some
guy $80000 a year to sit in a cubicle and draw icons for them!

Comment 40

[Robert Accettura [:raccettura]]

MS has used the IconFactory to design icons for them.  They did WindowsXP.

Comment 41

[Skewer]

JM: This appears to be an issue of personal preference. However I think the
majority of users will prefer the method I suggested which does not require
displaying file extensions. As for identifying the program which opens the file,
it should be obvious to the person who operates the computer what program opens
the file because he told that program to associate itself with the format. (Any
program that steals formats without permission excepted, of course.) Having that
red theme consistently throughout our icons is enough to identify Mozilla as the
program that opens the file. Furthermore (at least in WinXP) if you want to use
a specific program to open your file you can use the Open With menu.

At a bare minimum we would be making a big mistake if we were to use one icon
for all HTML, XML, and image formats. At least we need to separate HTML, XML,
and images because they're all completely different types of data. To say that
all formats should use the same icon defiles the whole purpose of having icons
in the first place.

Oh, and my problem with the 16-color icons was that they appear to have just
been converted from true-color... some of the Win98 icons were an example of
true mastery in 16-color iconography. Mostly had to do with mixing colors by
evenly alternating pixels of two different colors. If you can keep making icons
like this, though, I could probably touch up the 16-color versions.

Comment 42

[Skewer]

Attachment: Updated document icon w/ 16-color, XP formats

I added WinXP format icons (with the transparent drop shadow) and redid the
16-color icons. That lizard just can't look good in 16 colors, so I went with
the "m" instead. I think the small icon is the best of the 16-color icons I
made... anyone using a low-color display would be stupid to use a size like
48x48 so I'm not too worried that that one's not all that perfect.

Comment 43

[Skewer]

Attachment: Again, but viewable using a browser

Interesting, how both the file extension (.ico) and MIME type (image/x-icon)
seem to convey no information at all about the file's format. Oh well, a
mistake is only a mistake until it becomes common practice.

Comment 44

[Jez]

> This appears to be an issue of personal preference. However I think the
> majority of users will prefer the method I suggested which does not require
> displaying file extensions.

Probably right, although I really do wish MS and Apple hadn't 'dumbed down'
computing in this way.  Relying on an icon to identify a filetype is a terrible
idea.

> As for identifying the program which opens the file,
> it should be obvious to the person who operates the computer what program
> opens the file because he told that program to associate itself with the
> format.

Hmm, but there are so many diffent file handler programs, you might just forget.
 Personally, in a folder with hundreds of different files, I don't want hundreds
of different icons.  For me, the icons tell me very quickly what _program_ will
open the file, so I just want a few different ones (preferably), then I can
examine the actual filename for the filetype.  But as you said... personal
preference.  I'm not sure how Mozilla should deal with our differing views. 
Maybe give the option in Mozilla to customize the icons for different filetypes?
 Although that would rather defeat the purpose of the icons, because they're
meant to be assigned automatically, making easier for the user to idenfity
Mozilla-handled files.

> To say that
> all formats should use the same icon defiles the whole purpose of having icons
> in the first place.

Sorry to disagree, but if you're using icons, as I do, to identify which program
opens the file, it doesn't.  :-)

> Oh, and my problem with the 16-color icons was that they appear to have just
> been converted from true-color... some of the Win98 icons were an example of
> true mastery in 16-color iconography.

Heh, really?  When I go into 16 color mode, everything looks distinctly
horrible.  I thought my 16 color icons actually looked *better* than most
average 16 color icons.  Some programs don't even have 16 color icons!

> I added WinXP format icons (with the transparent drop shadow) and redid the
> 16-color icons. That lizard just can't look good in 16 colors, so I went with
> the "m" instead.

How can I put this... I think my icon looks better :-)  That olive green is
vile.  And the larger 'M' icons look slightly better than that barely readable
small 'M'.  I've always thought the italicised 'M' was very boring and
unimaginative, anyway... can't we stay consistent and use the dinosaur in 16
color mode?  I think we can get it to look at least acceptable.  Also, my color
reduction to 16 color kept the light/dark fade of the paper, using white/grey
dithering.  Doesn't that look nicer than your plain grey paper?

I like your Windows XP icons, though, let's keep those.  How did you do the
transparent drop shadow?  Microangelo doesn't seem to give me an option for that...

Comment 45

[José Jeria]

No offense, but, I have to say that the icon set at
http://grayrest.com/moz/resources/icons.shtml are still far better (more
proffesional) than any other icons presented here. They also match the existing
window icons very well. 

Comment 46

[Malcolm Scott]

Just to add my own opinion here... firstly I don't like the document icons at
grayrest.com, because they include the extension in the icon (see below).
However, they could be adapted and improved.

The issues here, as far as I can see, are:


1. Extensions in icons.

AFAIK, no other program puts the file extension within an icon. That's not what
icons are there for. If you want to see the file extension, look down a bit and
look at the filename (assuming you disabled hiding of extensions).


2. One icon, vs. Icon for each file type, vs. Icon for each group of file types

I agree with Jeremy Morton that having too many different icons is confusing if
you just want to see what program will open each file. Also, end users don't
really care that what's in front of them is a PNG Image, they just care that
it's an Image. But I also think that in a folder with e.g. 1 HTML document and
15 associated images, it should be easy to spot the HTML file, without having to
look at the file extensions (remember the default on WinXP etc. is to hide file
extensions). That was the original point of this bug.


So here's my suggestion: use some sort of page icon easily associated with
Mozilla - e.g. the top-right icon in Grayrest's set, or Jeremy's/Skewer's
red-page icon minus the lizard (with possibly the addition of a pale,
semi-transparent lizard, like a watermark on the page??), with various overlays
depending on what sort of file the user is dealing with. I suggest the following
icons:

Image  => .png, .gif, .jpg ...    => e.g. a paintbrush on a page
HTML   => .htm, .html, .xhtml ... => e.g. Jeremy's lizard-on-page
Script => .js, .xul, .css(?) ...  => e.g. a cogwheel on a page 
XML    => .xml ...                => not sure about this one
Link   => .url ...                => HTML icon with shortcut arrow?

How does that sound?

Comment 47

[Jez]

> No offense, but, I have to say that the icon set at
> http://grayrest.com/moz/resources/icons.shtml are still far better (more
> proffesional) than any other icons presented here.

I think mine look a lot better.  The ones on the left are OK, but not really
appropriate for files dealt with by Mozilla.  The ones on the right are nasty. 
They also use the boring, unimaginative italicised 'M' that reminds me a lot of
Netscape's "N throbber" that was criticised so much.  Let's make Mozilla look
GOOD.  Use the dinosaur! :-)

> One icon, vs. Icon for each file type, vs. Icon for each group of file types

I think I'll agree with the 'compromise' option; having the same icon for
different groups of filetypes.  I wouldn't have Mozilla associated with image
files, so I'd easily spot the HTML file from a load of image files, but I
suppose that if I did, I'd want different icons for the different group types. 
I think the 'icon on paper' is the most sensible compromise here, for the
*default* icons, at least.

I'd like to add that my personal experience with icons is pretty much limited to
Windows.  I've seen requests here for huge icons (128x128?!) that supposedly the
Mac supports.  There really is no reason to create these icons in sizes other
than 16x16, 32x32 and 48x48 for Windows, so from now on I'll be specifying my
submitted icons as specifically Windows icons.  (thank god i'm not using a Mac! :-)

Comment 48

[Jez]

Attachment: Windows 'blank' Mozilla icon

Created a 'blank' Windows Mozilla icon.  This should be a nice base from which
to work off, adding stuff on top of it to represent a certain group of
filetype.

- I've made the 16 color versions have the best 'dither' I can get.  I think it
looks better than just an all-grey piece of paper.
- I've worked out how to do the Windows XP alpha shadow, so I've put it in the
Windows XP versions of the icons and removed the shadow from the other versions
(as alpha transparency can't be achieved so shadow may be the wrong color, and
icon looks OK without the shadow).

Comment 49

[Jez]

Attachment: Windows 'watermark' Mozilla icon

The idea of a Mozilla 'watermark' on the icon was an interesting one, so I
created some 'watermark' icons.  As you can see, although it looks rather
gorgeous on the 48x48 version of the icon, it just doesn't work for the 16x16
version; I can't get the dinosaur head small enough to fit, and look like a
dinosaur head at the same time :-)  Also, you obviously can't do this for the
16 color version (you just get a grey blur) so I've left those as the standard
'blank' versions.  I'm not sure about the watermark.

Comment 50

[Malcolm Scott]

I really like that watermarked icon - even in 16x16. However, I'm not sure how
well this would work for the other categories of icon (images, scripts, etc.).
Would you add another overlay - e.g. a paintbrush for images - on top of the
watermarked page, maybe in the top-left corner? If so, would that look cluttered
or messy? Or would you replace the watermarked lizard with the paintbrush?

Comment 51

[Jez]

Attachment: Windows 'blank' Mozilla icon

Moved icon slightly to the right to allow to overlays to 'stick out' to the
left; apologies for the number of submissions.

Comment 52

[Jez]

Attachment: Windows 'watermark' Mozilla icon

Moved icon slightly to the right to allow to overlays to 'stick out' to the
left; apologies for the number of submissions.

Comment 53

[Jez]

Attachment: Windows 'HTML/XML' Mozilla icon

I've made a few improvements to my original 'general purpose' Mozilla icon
here.

- Now it includes Windows XP icons, with drop shadow.
- Non-Windows XP icons have no drop shadow.
- Significant improvement on the 16 color versions by using 'nearest color'
conversion and touching them up.  I dunno about you, but I think they look
pretty damn good for 16 color icons!!

I see no reason why XML should have its own icon.  This could be used for
several filetypes, XML one of them as well as HTML.

Comment 54

[Jez]

The watermark icon was created by putting the Mozilla head images over the blank
paper images with opacity 30.

> I really like that watermarked icon - even in 16x16. However, I'm not sure how
> well this would work for the other categories of icon (images, scripts, etc.).
> Would you add another overlay - e.g. a paintbrush for images - on top of the
> watermarked page, maybe in the top-left corner? If so, would that look cluttered
> or messy? Or would you replace the watermarked lizard with the paintbrush?

I'm not sure how cluttered it would look - it was your idea!  I was thinking
that the watermark would stay there for all icons, and the 'document group'
overlay would be added.  It may look cluttered.  However, if you're proposing
changing the watermark for each group of document, the only thing identifying
the document as being opened by Mozilla is the red-page icon!  If that is going
to be the 'Mozilla document' identifier, my origianl idea would seem the best;
just have that piece of paper with no watermark, and overlay the icon for the
document group?  Keeps the icon simple enough to be translated to 16 color, and
maintains a unique identity for Mozilla files.

But I definately like both the watermark AND the red-page better than the
blue/grey 'M' :-)

Comment 55

[Malcolm Scott]

> I was thinking
> that the watermark would stay there for all icons, and the 'document group'
> overlay would be added.  It may look cluttered.

Yes, that was my original thought too. I only realised later that it may look
cluttered. I suppose the only thing to do is to try it... do you (or does anyone
else) have any overlay icons that could be used?

> However, if you're proposing
> changing the watermark for each group of document, the only thing identifying
> the document as being opened by Mozilla is the red-page icon!

Um, yes. I may have lost the plot there for a moment :-) You can ignore the
suggestion of changing the watermark.

> If that is
> going to be the 'Mozilla document' identifier, my origianl idea would seem the
> best; just have that piece of paper with no watermark, and overlay the icon
> for the document group?  Keeps the icon simple enough to be translated to 16
> color, and maintains a unique identity for Mozilla files.

So this question remains: is a red page sufficient as a 'Mozilla document'
identifier, or do we want the watermark as well? As it stands at the moment, I
prefer the watermarked page, but if this ends up looking too cluttered it may be
better to use the non-watermarked page.

> But I definately like both the watermark AND the red-page better than the
> blue/grey 'M' :-)

Agreed :-)

Comment 56

[Jez]

It's just been pointed out to me that 16 color mode is just about never used
anymore.  XP won't let you use 16 colors, and virtually nobody uses it at all. 
Why are we making icons for 16 color mode screens?  Is there any really good
reason for it, because if not, the watermark idea suddenly seems more feasible.

Comment 57

[Malcolm Scott]

Considering that many programs don't have 16-colour icons, and that people using
16-colour mode surely expect things to look foul anyway, you could make a case
for ignoring 16-colour icons altogether. I think high-colour-depth icons have
been the default since Win98 (although I'm not certain) - but there was
certainly an option to force 16-colour icons in Win98.

If it's not much more effort, you could just use the non-watermark version for
16-colour and keep the watermark in place for higher colour depths.

Comment 58

[Alex Hosking]

There ems to b a Million and one atchments here, Check something in, Eben if it
sucks you can always change it later!

Comment 59

[Jez]

Re: comment #57

Yep, seems like a reasonable idea, Malcom.  Will have to see how 'cluttered' the
watermark + overlay icons seem.  Can you think of a decent overlay for HTML/XML
documents, though?  I was going to use the Mozilla head as the overlay for them,
but if it's a watermark, it'd be dumb to put it as the overlay too.  Can't think
of anything better, though.

Comment 60

[Brian 'netdragon' Bober]

This is similiar to bug 214054 except that bug is for firebird. Should it be a dupe?

Comment 61

[Malcolm Scott]

Comment 59: perhaps a globe for HTML files?

Comment 60: probably shouldn't be a dupe, unless Firebird plans on using the
same icons as Seamonkey.

Comment 62

[Skewer]

Wow, so much has happened.

First of all, looking at ALL the icons submitted that have not been declared
obsolete, I find attachment 128636 [details] to be the best overall icon. The watermark
icon is kind of dumb, it violates pretty much every accepted practice of icon
design for WinXP. The proper way to do it is attachment 128636 [details]. I think that
icon would be the best choice for HTML and any default Mozilla associations
(ones which don't yet have their own icons).

Comment 45: NO. N-O. Those icons are terrible. #1, the Mozilla "m" is not
correct; compare it to the throbber and you will see how different they are. #2,
the file extension is printed in the icon, a huge no-no. Icons should
communicate the file type inherently by using symbology, not by printing the
extension. This is particularly embarrasing when you have a filetype of
text/html but the extension isn't necessarily .html (e.g. .htm, .shtml). If I
could veto those icons I would, they're a step backwards from even what we do
now (using the appicon for associated files).

Comment 57: I think 16-color is a good fallback for the worst-case scenario
(safe mode is always fun when you see what happens to the icons). However if
they were removed I wouldn't complain because 16 color is such a rarity (though
I would like to know how well the truecolor icon works in a more feasible
situation like 8-bit color or 16-bit color... we need to check that out). I
think Jeremy's revised 16-color icons in attachment 128636 [details] are much better and
those would be exceptional in such a situation.

Comment 60: That bug should be duped to this one unless Firebird intends to use
different filetype icons.

As for the other file types, I'm going to submit some prototypes based on
attachment 128633 [details]. I'll make something for XML and GIF (the GIF will be a shapes
icon similar to our placeholder, should be usable as a default image format icon
also). I'm just going to do the XP icons to start; if you like them I can do
other formats. What I'm thinking though, is that I will use a tree for PNG and a
little digital camera for JPEG unless anyone has better suggestions.

Comment 63

[Skewer]

Attachment: XML icon (XP format only)

Comment 64

[Skewer]

Attachment: GIF icon (XP format only)

Comment 65

[Jez]

Skewer: a couple of things:
Could you tell me how you added the Windows XP drop shadow in attachment #128602 [details]
and attachment #128603 [details] ?  I'd quite like to know what 'tool' you used.

Second, we've got to get this fundamental debate sorted out before we start
really designing the non-general icons; some people want one icon for every file
type (me :-) and some want a different icon for every file type (you :-).  If we
had a different icon for every filetype there would be HUNDREDS of different
icons on the computer.  That would drive me mad!  Now, I think a good compromise
between these views is the one proposed by Malcolm Scott in comment #46 - have a
select few different icons, for different *groups* of filetypes.  I think the
groups he lists there are just about right; image, script, link, and the only
change i'd make is to combine XML and HTML, they're too similar to warrant
different icons.

So, how about, instead of making an icon for every different image type and
document type and script type and everything (we'd get about 50 icons,
literally), we have an icon for:
- ANY image format.  GIF, JPEG, PNG.  Paintbrush overlay?
- ANY script format.  JS, XUL.  Cogwheel overlay?
- ANY link.  URL.  Arrow overlay, but not the same as the default windows 'link'
arrow so as to avoid confusion with an 'official' OS link?
- ANY document format, and 'default' for a group that doesn't yet have an icon.
 HTML/XML.  I suggest attachment #128636 [details].

In addition, an icon for any significantly different group of documents, handled
by Mozilla, that I didn't mention up there.  Wouldn't that be reasonable?  More
reasonable than one icon for each and every different filetype, anyway. ;-)
- HTML, XML and any other 'm

Comment 66

[timeless]

let's get some basics straight

A: .xul and .js are totally unrelated. xul is a document, js is a script.
don't dream of using the same icon for those two.

B: JPEG and JPG should use the same icon and it should not appear incorrect for either.

C: IE chose not to use the same icon for GIF and JPG, since IE is made by the vendor who designed the icon specs for the OS in question, do you think it might be a good idea to follow their lead?

D: You're welcome to group arcane formats under generics, esp say RDF as XML.

E: To everyone looking at this bug, please don't complain about the number of attachments, and please don't think that because we have attachments we should commit them.

F: to people attaching things, ... um... could you please try making the fewer than 25 icons listed in the first attachment's second table? (shtml can be the same as html but there is a reason to make it different. shtml covers asp, jsp, psp, and any other html like file which has server processing instructions which would mean that loading the file in a browser w/o running it through the processor may result in garbage. in my world, mozilla would not take over any of those types unless there isn't an owner.)

Comment 67

[Jez]

> .xul and .js are totally unrelated. xul is a document, js is a script.

Right.  Didn't remember what XUL was, it's Mozilla's new bizarre user-interface
thingy, isnt it.  I can't think of any scripts other than JS that might be
handled by Mozilla, though.

> IE chose not to use the same icon for GIF and JPG, since IE is made by the
> vendor who designed the icon specs for the OS in question, do you think it
might > be a good idea to follow their lead?

No.  People here are always criticising IE for all kinds of things, don't now
turn round and use it as a reason to do something.  I personally dislike IE's
different icons for GIFs and JPGs, but at least that's only 2 seperate icons. 
Does it have different icons for TIFFs, PNGs, BMPs, RAWs, etc?  I doubt it
handles all of them, so no.  The problem is that Mozilla can handle many, many
filetimes, so I think it's only sensible to begin grouping them together for the
sake of avoiding icon madness.  One icon, for ALL image types.

> to people attaching things, ... um... could you please try making the fewer
> than 25 icons listed in the first attachment's second table? (shtml can be the
> same as html but there is a reason to make it different.

Ye gods, SHTML and HTML are perfect examples of files that ought to have the
same icon.  They're both documents, and they both result in outputted HTML. 
Please, don't start insisting of 25 different icons for Mozilla.  That would be
really annoying.  Ideally there would be maybe 5 icons at max, for general
groups of icons.  If you totally disagree on this so much as for it to be
unacceptable, perhaps there ought to be a preference on install because I DO NOT
want 25 different Mozilla file icons.

Comment 68

[Brian 'netdragon' Bober]

For comment #65 - we can have a general Mozilla filetype icon, but allow for it
to be overriden for specific extensions/groups of extensions if such an icon
exists. I agree that one icon for all images is sufficient (bug #67)

The way icons are hooked up within Mozilla is a hack at best (i.e. inconsistant
naming 199576) and its so hardcoded, and this will just add more chaos to it if
its not all rewritten. 

I also believe there should be an icon module that contains all the icon
resources and they are placed on Windows within a DLL file. Every icon but the
program icon should be within that new component and DLL, including Window
icons, etc. See bug 214174, since I also mentioned what would happen for
association icons within this scheme of rewriting the way icons are hooked up.

This also affects Linux as some window managers (i.e. Gnome) allow for
associations and the icons need a 48x48 version so that they can easily be
available within the binary directory on Linux.

Comment 69

[Brian 'netdragon' Bober]

Just fixing up a couple links:

not bug #67, but comment #67
bug 199576 <- I forgot to write bug

Comment 70

[Brian 'netdragon' Bober]

See http://bugzilla.mozilla.org/show_bug.cgi?id=214174#c2 and
http://bugzilla.mozilla.org/show_bug.cgi?id=214174#c3 for a description of how
the icons could be mapped to associated file types.

Comment 71

[timeless]

shtml/html was my example of an edge case, i put forward the argument for why you could keep them as distinct, but am not demanding that they be distinct.

as for scripts, here's my list of scripts which might be handled by some mozilla(derivative):
applescript, javascript, perlscript, pythonscript, tclscript, vbscript.

how?
komodo(a mozilla derivative) could use perl/python.
tcl and vb could be handled by activescripting support (which someone could add).
applescript can be supported if someone offers glue for it on macos (i think there was glue for mozilla/4 or thereabouts).

should mozilla actually own .js?
maybe, probably not.

js files as executables are better owned by a scripting host (xpcshell, wscript/cscript). mozilla doesn't actually do anything useful to a .js file if it's fed it directly. (arguably it could be wired to launch venkman, but i can't imagine anyone actually making that argument.)

generally bmp, gif, jpg and png all have different icons. (bmp comes from mspaint. gif/jpg would be from iexplore. i can't remember who supplies png. tiff would come from something else and would definitely haves its own icon, probably from [wang/kodak]imaging.)

perhaps the question to ask is what's the purpose of the icon? is it to indicate what app will open the object or what the object is?

if the argument is made for what app would open the file then just leave things be with the windows generated icon. (this is a straw man, i don't support it)

if the argument is to show what the object is, then why should we change the icon just because we're the new owner of the object. (this might be a straw man.) in this view things which have icons (.js, .htm*, .jpg, .gif) should just keep their current icon and we should just take ownership of the verb.

How is this useful?
The user picks <foo> to become the owner of HTMLFile.
an htmlfile is still an htmlfile, it hasn't changed, the user doesn't need to be surprised by different looking objects. the objects haven't changed, they're still html files.  Windows XP and beyond are actually heavily leaning in this direction, apps register which things they can support and then the context menu or whatever lets you open using/with a suggested/used application.  The idea is that the user cares about what the object is and what it contains not what app will load it. if the user cares about the app then the user will select this special menu and pick a specific app, or the user will drag the object to the app.

Also note that in thumbs view there are 3 images, the object type, the app owner and the object preview. Spending most of your icon pixels to identify your app when the app icon is indicated elsewhere is a poor design decision.

In this view we should basically draw art only for icons which the system doesn't include (rdf, xul, jar, xpi). each of these is relatively distinct. their behaviors are definitely distinct. and by changing the focus to these icons the bug should become a lot less interesting.

Comment 72

[Jez]

> should mozilla actually own .js?
> maybe, probably not.

Fine, but it does own some scripts, so a script icon is still warranted.

> perhaps the question to ask is what's the purpose of the icon? is it to
> indicate what app will open the object or what the object is?

Ideally, it indicates both of those things.

> How is this useful?
> The user picks <foo> to become the owner of HTMLFile.
> an htmlfile is still an htmlfile, it hasn't changed, the user doesn't need to
> be surprised by different looking objects. the objects haven't changed,
> they're still html files.  Windows XP and beyond are actually heavily leaning
> in this direction, apps register which things they can support and then the
> context menu or whatever lets you open using/with a suggested/used app.

What universe are you living in??  I vearly never use ANYTHING but the default
app to open a file, and I run Windows XP.  Occasionally I will drag/drop, if i
have to, or use 'File | Open', having opened an app, to open a nonstandard file
for that app, but i never use the 'open with' menu.  I don't know anyone that
does, either.

> The idea is that the user cares about what the object is and what it contains
> not what app will load it. if the user cares about the app then the user will
> select this special menu and pick a specific app, or the user will drag the
> object to the app.

It may be the idea, but it's not the practice.  It's far easier to use the
default associated program to open a file than anything else, and in practice
you're likely to just be opening it with one program 99% of the time anyway. 
Thinking carefully about it, I care equally about the file type and what app
will load it.  Obviously, I would want to know that something is an HTML file if
I'm opening a local webpage to view, but I'd also like the icon to indicate to
me that Mozilla will open it.  Where you got the idea that XP is 'leaning
towards' the icon just identifying the file type is beyond me.  The default icon
for HTML is the very recognisable blue page with the Internet Explorer icon
overlaid on top of it.  Hardly application-independent.  The default icon for a
Microsoft Word document is a page with the Microsoft Word logo overlaid.  Hardly
application-independent.

> Also note that in thumbs view there are 3 images, the object type, the app
> owner and the object preview. Spending most of your icon pixels to identify
> your app when the app icon is indicated elsewhere is a poor design decision.

Heh, it's possible to get 3 images??  I just tried and honestly can't even work
out how to get this feature.  When I go into thumbs mode, I just get a much
larger-than normal icon, but I browse with my folders list on the left, not some
stupid colorful toolbar with a preview image in it.  Therefore, I get one image;
the icon.

> In this view we should basically draw art only for icons which the system
> doesn't include (rdf, xul, jar, xpi). each of these is relatively distinct.
> their behaviors are definitely distinct. and by changing the focus to these
> icons the bug should become a lot less interesting.

No, I disagree.  We most definately should draw art for ANY FILE associated with
Mozilla.  Drop the argument about icons identifying purely filetypes.  The
average end-user *fully expects* an icon to convey not just the general kind of
file that they're dealing with, but also the application that deals with it, by
the unique styling of the icon.  This is what makes operating systems look nice,
and gives different applications character.  If you change the application
dealing with certain filetypes, the icons for those filetypes *should change* to
reflect that fact.  Period.

Comment 73

[Brian 'netdragon' Bober]

timeless: For some strange reason, your comments don't wrap (Netscape 7). :-)

> perhaps the question to ask is what's the purpose of the icon? is it to 
> indicate what app will open the object or what the object is?

I'd say both, and its more important for the icon to say, "Its some kind of
image that will be opened by Mozilla" than "This is a TIFF image" or "This is
something Mozilla will open". Associations are between two entities, and not
just a reflection of one. I don't see really a reason to show something more
specific than a generic image icon with a Mozilla head on it for all images. If
we want to ever make it more specific, we could just put the extension in small
letters on the bottom of this generic image as is done for some peoples' apache
server directory browser icons. This might be helpful for people on Windows who
have the file extensions turned off so they can see what kind of image it is.
Each icon on Windows would add about 30k of uncompressable bloat to the binary
size. Because of that, I think we should just have one icon for all image
formats, and if people want to do it more specific, they could install an
extension from mozdev which would provide the more specific icons in a dll file
or something (we'd need to make the association icons extensible then which
brings us back to the icon code mess and bug 214174).

> The idea is that the user cares about what the object is and what it contains 
> not what app will load it. if the user cares about the app then the user will
> select this special menu and pick a specific app, or the user will drag the 
> object to the app.

I use many different apps to open the same file type. I will usually have the
default application as the one I use the most. In that case, it helps for me to
see which application opens it by default to help me remember. Otherwise, I will
choose "Open With" if the default application is not the one I want to use. For
images, I have some viewer that loads quickly as the default application since
I'm usually just viewing the image. I guess Mozilla would fall into that
category. I would want this viewer (M$ Image Browser, ACDSee, etc) reflected on
the icons so I know if I want to use a different app to view the image, or edit
it that I will right click and choose "Open With". That is why it makes sense to
have the Mozilla logo on all association icons such as the example I will make
for all images that I'm about to attach (just for demonstration purposes, as a
.png containing multiple sizes). It will have to wait till I get back from an
appointment.

We also have to make sure that when we change back associations because a user
removes them, that the icons for the associations are changed back too.

> Also note that in thumbs view there are 3 images, the object type, the app 
> owner and the object preview. Spending most of your icon pixels to identify 
> your app when the app icon is indicated elsewhere is a poor design decision.

You are assuming people have that feature turned on or available on their
system, but I wouldn't assume that. Combining a little logo of the application
with the image describing the file type on the icon is standard practice. Look
at photoshop for instance. The little dino head can be as small as 4x4 on a
16x16 and 8x8 on a 32x32 image if its done right (examples later).

> In this view we should basically draw art only for icons which the system 
> doesn't include (rdf, xul, jar, xpi). each of these is relatively distinct. 
> their behaviors are definitely distinct. and by changing the focus to these 
> icons the bug should become a lot less interesting.

I have different preferences, but perhaps we should give them the option to use
the standard system icons for known file types even if they are associated with
Mozilla.

Comment 74

[Skewer]

Okay, we have to settle this argument.

First, some general points:
To my knowledge, we don't associate with JS, CSS, URL, or a bunch of other
mentioned filetypes. We probably should and we will probably need icons for them
eventually, but for now it's moot.

Now, we have Jeremy Morton, who thinks:
j1. All formats owned by Mozilla should use the *same* icon. (Later compromised
that all image formats could use an image format icon but JPEG/PNG may not be
distinct.)
j2. Demands that Mozilla's icon set be recognizable as Mozilla-owned. I think
the red page does that very nicely even in the XML and GIF icons I made. I
challenge Jeremy or anyone else to find me any other program that uses a red
page on its associated icons.

Then there was timeless who stated:
t1. Every format ought to have its own icon, even SHTML should be distinct from
HTML.

I think most of Jeremy's arguments are just self-interest; nothing he's
suggesting is proper for the Windows environment. It should definitely be
possible to tell an HTML from a JPG and he's admitted that, but also we need a
different icon for JPEG/JPG, PNG, and GIF formats because all three are
completely different. I don't think the lesser formats (MNG, JNG (if that ever
gets put back in), SVG, and BMP are as important and they could just use the
default GIF icon. As for ICO I think it's kind of, nay, very stupid that we
associate with that at all. But the proper thing to do with associated ICO files
is to not assign an icon to them at all, and let them be displayed as the icons
they are. As for some other formats, XHTML is close enough to HTML to use the
same icon, XML (and its partners RDF and DTD) can use the XML icon, JS/CSS we
don't take, XUL is little used in the wild and doesn't need its own special icon
(default to HTML icon), and should the day come that we associate with URL we
should use either the HTML icon or the site's favicon if applicable, and there's
some method to get Windows to draw an arrow overlay. We don't offer
SHTML/PHTML/etc. association so let's not worry about that, but I would still
say use regular HTML icon for those.

Comment 75

[Skewer]

  I don't see really a reason to show something more specific than a generic
  image icon with a Mozilla head on it for all images. If we want to ever make
  it more specific, we could just put the extension in small letters on the
  bottom of this generic image as is done for some peoples' apache server
  directory browser icons.

NO SMALL LETTERS! Arrgh. I don't have to explain *again* why that is stupid, do
I? Technically if you turn on the status bar or view properties you can access
the file's "type" (HTML document, JPEG image) provided Mozilla is associating
properly. This is not a reason not to provide distinct file icons however. As
for the Mozilla head, not really necessary, it would be too much clutter if that
was added to the image icon. The red page identifies Mozilla just fine (see
challenge above). It's not possible to add a Mozilla head to the image icon and
have it look good.

The bloat issue is kind of silly, as is the bloat issue in the MNG debate, but
it would indeed be a problem if we had 25 different icons.

  I have different preferences, but perhaps we should give them the option to
  use the standard system icons for known file types even if they are
  associated with Mozilla.

Yet another candidate for "worst reason to create a pref ever." Let's just do it
right from the beginning. Besides wouldn't this option violate the "golden rule"
you and Jeremy have made up about identifying the associated program?

Comment 76

[Malcolm Scott]

  Skewer >  we need a different icon for JPEG/JPG, PNG, and GIF formats because
         >  all three are completely different

How different really are they as far as an end-user is concerned? Most users
will simply care that it's an image, rather than that it's an image that happens
to be stored in the PNG format.

But if you insist on using separate icons for the three major image formats, how
do you suggest differentiating between these icons in a meaningful way (without,
of course, resorting to printing the extensions on the icon... or other no-nos
such as simply changing the colour of a picture frame, as I believe Microsoft
used to do to distinguish image formats)?


And on another matter, I agree that the red page is just about sufficient to
distinguish an icon as mozilla-owned, but I believe the watermarked version
looks more professional, and it also emphasises the association with Mozilla by
including the ubiquitous lizard head. And some of us happen to prefer the
watermarked version.

Comment 77

[Brian 'netdragon' Bober]

Attachment: Demonstration icons with mozilla head (png images)

I attached some examples of what I was thinking of for the generic image icon
which I believe is sufficient for all image formats.I didn't put much effort
into them since they are only for demonstration.

Some selected quotes:
> What universe are you living in??
> I don't have to explain *again* why that is stupid, do I?
> I think most of Jeremy's arguments are just self-interest; nothing he's
> suggesting is proper for the Windows environment.

***Please refrain from personal attacks within Bugzilla***

If you are extremely angry at someone, please talk to them personally via email
or some other means. Otherwise, we will have to rename Bugzilla to Flamezilla.

By bloat, I meant something like 25 different icons (think about just the
number of image formats we support). 25*30k=750k of uncompressible data. We
should allow extensions for that.

We shouldn't support all formats a derivative of GRE might allow. The
derivative should be able to install its own icons by using xpinstall or the
GRE. That's the idea: Code it properly, and make it extendable, and therefore
we won't bloat the GRE or Mozilla distribution with uneeded files. The general
image icon will suffice for all image formats. We don't need to have icons for
things like pdf, etc because that is handled by plugins. js is really
questionable.

>Yet another candidate for "worst reason to create a pref ever." Let's just do
>it right from the beginning. Besides wouldn't this option violate the "golden 

>rule" you and Jeremy have made up about identifying the associated program?

What is your definition of right? I was just coming up with a solution to
timeless saying some people won't like the icons changed even if a new
application is associated. I do agree that some people will not want the icons
changed even if the association is. Is this a big enough issue to warrant a
preference? I don't really think so. I don't think there is really a right or
wrong when it comes to that, though. Its all about preference. UI purists
forget that people have different needs in terms of functional UI.

Perhaps there is something in the Windows application design specification
http://bugzilla.mozilla.org/attachment.cgi?id=26342&action=view to give us a
better idea of what Microsoft is intending.

Comment 78

[Skewer]

  But if you insist on using separate icons for the three major image formats,
  how do you suggest differentiating between these icons in a meaningful way
  (without, of course, resorting to printing the extensions on the icon... or
  other no-nos such as simply changing the colour of a picture frame, as I
  believe Microsoft used to do to distinguish image formats)?

I'm curious why using different colors is considered a no-no? I think that's a
very effective way to differentiate. The method I suggested earlier however is
default icon (already partly made) for GIF, tree for PNG, digicam for JP(E)?G.

  And on another matter, I agree that the red page is just about sufficient to
  distinguish an icon as mozilla-owned, but I believe the watermarked version
  looks more professional, and it also emphasises the association with Mozilla
  by including the ubiquitous lizard head. And some of us happen to prefer the
  watermarked version.

Look at the IE HTML icon. Look at the Windows Media Player icon. Look at the
WinZip icon. What do they have in common? A floating, left-aligned identifying
logo. I challenge you (another challenge) to find any high-profile WinXP app
that uses this watermark method instead of the floating image. We can be
beautiful by fitting in. Just because the watermarked icon looks nice by itself
doesn't mean it's going to be acceptable in the real world of associated file icons.

  If you are extremely angry at someone, please talk to them personally via
  email or some other means. Otherwise, we will have to rename Bugzilla to
  Flamezilla.

Personally I'm not angry at anyone... but I am correcting a few misconceptions
before anyone goes to the trouble of making worthless progress on this bug based
on those misconceptions.

As for attachment 128744 [details], that would look bad whether you put effort into it or
not, because this is another case of "let's make up our own arbitrary behavior
for filetype icons so we can squeeze some branding into the icon," not unlike
the watermark thing. Which is really what this is about: Is there truly a need
for us to put our branding on the filetype icons? If anyone who isn't on a
shared system or anything like that is surprised by an association being tied to
our program, then we are being too pushy with grabbing associations. Otherwise
the person would be well aware (and only need the red-page cue) that the file
will, by default, open in Mozilla. Having said that I don't see any reason why
we shouldn't use the XML and GIF icons as I demonstrated. And although it
wouldn't be 100% correct, I think if we had an HTML, XML, and image icon (first
is done, next two can be finished in about 10 minutes by me) and got them
checked in together with necessary, expandable code, it would be great progress
(certainly enough to warrant marking this bug FIXED). After that we can discuss
the merits of JPEG/PNG identification in a new bug.

And please consider for a moment, that I will never associate image file types
to Mozilla. I have no reason to personally want this. It's just the correct
behavior; it allows me to look at a folder full of images (in less than the
clunky thumbnails mode) and tell whether an image is the full-size JPG grabbed
from my digital camera, the optimized 8-bit PNG for my site, or the BMP file for
use as wallpaper (default icon). Don't forget that the icon isn't just for
Mozilla's purposes; this is what you will look at when you need to pick out a
file to upload in an FTP program, or the file to burn to a CD-R. It may
ultimately be decided by someone in charge at Mozilla that there's no reason to
have JPEG/PNG icons simply because that would cause a bloat issue or because
smart people don't usually assign image filetypes to Mozilla, or some other
valid reason, but it is indeed the correct behavior.

Oh, and to put down the myth of the need for a pref to retain old icons: Anyone
who actually cares about something that trivial will know how to manually tweak
it anyway. Not worth the trouble of a pref.

Comment 79

[Malcolm Scott]

> I'm curious why using different colors is considered a no-no? I think that's a
> very effective way to differentiate.

My point was that if there is indeed some difference between image types to the
end-user above "it's just an image", then the icons should show these
differences. People shouldn't have to remember "red=PNG, green=JPEG, blue=GIF"
etc. That's pointless. (It took me a long while to get used to the icon colour
coding IE used to use.)

You go on to suggest a perfectly workable solution, so my question has been
answered - based on the assumption that GIFs are used for odd shapes, bits and
pieces, etc., JPEGs are used for photos, and PNGs for anything in between.


> Look at the IE HTML icon. Look at the Windows Media Player icon. Look at the
> WinZip icon. What do they have in common? A floating, left-aligned identifying
> logo.

OK, but IE is also inconsistent - there's no identifying logo on the non-HTML
filetypes owned by IE (scripts, images, etc.).

Anyway, you go on to say:

> Is there truly a need for us to put our branding on the filetype icons?

...which seems to me to be a contradiction. First you're advocating putting a
floating, left-aligned identifying logo on the icon, in the style of IE etc. -
presumably the mozilla head - then you're debating whether to put the head in at
all.

The problem with the examples you gave above is that they use identifying logos
to show which program will be used, but they have no way of distinguishing
different filetypes. WinZip, Media Player, etc. use the same icon for every type
of file they can open. Whilst I'm _NOT_ advocating this for Mozilla, I'm saying
that we face another debate: should the overlayed icon identify the program
(e.g. Mozilla head) or the filetype (e.g. paintbrush for images)?

Both of these methods are in use in a default Windows XP installation: some
filetypes (e.g. HTML) have a logo which tell you "this will open in IE", whereas
others (e.g. images) have icons which just tell you "this is an image" and give
no clue as to what they'll open with.

If we use the second method - where the overlay identifies the filetype - you
would say that the red page is a sufficient indication that a file opens with
Mozilla. But where's the harm in adding the watermark? This will make the
association clearer to people unfamiliar with Mozilla's icons. Granted, nothing
else uses a watermark, but do you know of any other application's icons which
clearly convey both file type _and_ application information, for a number of
different file types? IE doesn't manage it. Just because no-one else has done
this yet doesn't mean we shouldn't try it!

Comment 80

[Jez]

> It's just the correct
> behavior; it allows me to look at a folder full of images (in less than the
> clunky thumbnails mode) and tell whether an image is the full-size JPG grabbed
> from my digital camera, the optimized 8-bit PNG for my site, or the BMP file for
> use as wallpaper (default icon).

Or you could just enable file extensions.  Or you could keep these totally
different documents in different directories.  Or you could actually give them a
meaningful name (desktop.bmp, website-logo.png) instead of relying on an ICON to
tell you.  Honestly, I HATE this idea of having a different icon for every
single filetype!  It's ridiculous.  Do you have any idea how many different
image formate there are out there?  Paint Shop Pro alone supports over 30.  And
if Mozilla started to support even 10 (hint: it already does around 5), can you
imagine the fun of dreaming up new icons for each type?  It wouldn't be fun, it
would suck.

We need one icon for each document GROUP.  Not each document EXTENSION.

Comment 81

[Brian 'netdragon' Bober]

Personally, I don't think any icons should be checked in until the way icons are
included in the tree is cleaned up. Its a real mess, and if you don't believe me
or think I'm overreacting, email me or ask in bug 214174 and I'll give a very
detailed code-level explanation of why its a bad hack at best, and shouldn't be
extended without being cleaned up. I hope other developers would agree.
Modifying the way icons are handled or adding icons the way it is right now is a
real pain in the neck and this will only compound the problem.

As for branding... The red icon is still branding in a way, and the question is
whether its enough for people to know its associated with Mozilla. The floating
logo is the most common thing I have seen applications do to identify themselves
as the default application and I see nothing wrong with it.

>Look at the IE HTML icon. Look at the Windows Media Player icon. Look at the
>WinZip icon. What do they have in common? A floating, left-aligned identifying
>logo

Then why are you arguing for us to not use one and just use a color instead?

>let's make up our own arbitrary behavior
>for filetype icons so we can squeeze some branding into the icon,

You just said the floating logo was the common thing. The only difference was
the dino head was on the right on mine. Since you are advocating it on the left,
and mine was just a demonstration of what I was talking about, then I was
demonstrating what you are advocating with just an error on dino head placement.

>If anyone who isn't on a
>shared system or anything like that is surprised by an association being tied
>to our program, then we are being too pushy with grabbing associations.

We are kind of pushy with grabbing associations on first installation, and also
sometimes people say "Yes" to making it the "default browser" which most people
don't understand means "associate with document files". Besides, sometimes when
you have a lot of applications you use for a particular filetype, you forget
which program its associated with and the dino head would be a clue. And I'm not
making this last thing up but talking from experience.

> and got them
> checked in together with necessary, expandable code,

Yes. Once the icon code were cleaned up and not made to be so hard-wired, fixing
this bug or adding new association icons would be a very small and simple patch.
I believe that at that point, we could let just let kerz or someone else with
checkin privs make the final decision and check the icons in. We could then wait
for user reaction to the chosen association icons.

>and tell whether an image is the full-size JPG grabbed
>from my digital camera, the optimized 8-bit PNG for my site, or the BMP file
>for use as wallpaper (default icon).

Turn on seeing file extensions in explorer. If this is the reason you want it,
then we shouldn't differentiate because not having file extensions visible in
explorer is a big security risk. People sometimes make executables that have an
image icon but are really a virus. Unsuspecting users run the program.

This isn't an important enough thing to warrant the extra almost 1 meg of bloat,
and checkin work the developers need along with tree maintenance. If the icon
code is extensible, then an application could simply just install another DLL
file into the directory and add the associations at the user's request.

>Anyone 
>who actually cares about something that trivial will know how to manually tweak
>it anyway. Not worth the trouble of a pref.

That is a lot of work for people. But oh well, I guess if they are that anal,
they will be used to doing the work themselves. If this code were extensible,
this issue could be solved by an extension too.

> I'm saying
> that we face another debate: should the overlayed icon identify the program
> (e.g. Mozilla head) or the filetype (e.g. paintbrush for images)?

The overlayed image should be the Mozilla head so most of the icon is devoted
for the filetype.



I looked at the watermark icon in Linux, and I don't get how it conveys anything
about Mozilla. Do you have to see it on Windows? I'd like it if Mozilla could
use the same style for icons cross-platform as much as possible.

>I HATE this idea of having a different icon for every
>single filetype!  It's ridiculous.

Agreed.It creates clutter.

Comment 82

[Brian 'netdragon' Bober]

http://bugzilla.mozilla.org/attachment.cgi?id=26342&action=view

Excerpts:

1.6    Ensure non-hidden files outside of your application directory have
associated file-types with icons, descriptions, and actions

Every file that does not have the hidden bit set that your application creates
outside its directory in "Program Files" (see requirement 2.4) must have an
associated registered file-type. This includes:

·         Files created during installation

·         Implementation and data files

·         User created files that are native to your application

If the file-type is already registered, no action is required, though you may
take over the file-type if you wish.

If the file-type is not already registered, you must do the following for each
new file type:

·         Provide an icon so that none of the files that your application
creates is identified by the default Windows icon.

·         Provide a friendly type description, for example, “Outlook Offline
Mail File.”

·         Ensure that each file-type has an associated action when
double-clicked (e.g. launch your application and load the file), or is
designated as “NoOpen”.

The NoOpen designation may be used for files that you don’t want users to open.
When the user double-clicks a file marked as NoOpen, the operating system will
automatically provide a message informing the user that the file should not be
opened. Note that if an action is later associated with a NoOpen file type, the
NoOpen designation will be ignored.

Exception:

If your application allows the user to save or export file types that aren’t
native to your application, the user may choose to save a file as a type that
has no association on the user’s computer. Your application may save the file as
requested by the user, even though the file will have a default Windows icon.






7.       Avoid text in bitmaps and icons, as these are difficult to localize.


I don't think that txt or svg, etc would need to be localized if we did include
that in the ico which I guess some people oppose.




Too bad it says nothing about appearance of icons.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch14f.asp

This does: "Icons for documents and data files should be distinct from the
application's icon. Include some common element of the application's icon, but
focus on making the document icon recognizable and representative of the file's
content." (See below)


Therefore, our discussion is solved.



Icon Design

Icons are used throughout the Windows interface to represent objects or tasks.
The system uses icons to represent your software's objects, so it is important
to design effective icons that communicate their purpose.

Design icons as a set and consider their relationship to each other and to the
user's tasks. Do several sketches or designs and test them for usability.
Sizes and Types

Supply icons for your application in 16-color and 256-color versions and in
three sizes: 16 x 16 pixels, 32 x 32 pixels, and 48 x 48 pixels, as shown in
Figure 14.32. The 256-color icons are used in 16- and 24-bit color display modes.

Two color versions in three sizes of icons (zoomed)

Figure 14.32 Two color versions in three sizes of icons (zoomed)

NoteNote

To display icons at 48 x 48 pixel resolution, the registry value Shell Icon Size
must be increased to 48. To display icons in color resolution depth higher than
16 colors, the registry value Shell Icon BPP must be set to 8 or more. These
values are stored in HKEY_ CURRENT_USER\Desktop\WindowMetrics.

Use colors drawn from the system palette to make sure that icons look correct in
all color configurations.

The system automatically maps colors in your icon design for monochrome
configurations. However, check your icon design in a monochrome configuration.
If the result is not satisfactory, include monochrome icons as well.

Define icons not only for your application's executable file, but also for all
data file types supported by your application, as shown in Figure 14.33.

Application icons and supported document icons

Figure 14.33 Application icons and supported document icons

Icons for documents and data files should be distinct from the application's
icon. Include some common element of the application's icon, but focus on making
the document icon recognizable and representative of the file's content.

Register the icons you supply in the system registry. If your software does not
register any icons, the system automatically provides one for your application,
as shown in Figure 14.34. However, it is unlikely to be as detailed or
distinctive as one you supply.

Cross referenceMore Information

For more information about registering your icons, see Chapter 11, "Integrating
with the System."

System-generated icons

Figure 14.34 System-generated icons for a file type without a registered icon
Icon Style

Use a common design style across all icons. Repeat common characteristics, but
avoid repeating unrelated elements.

An illustrative style tends to communicate metaphorical concepts more
effectively than abstract symbols. However, if you design an image based on a
real-world object, use only the amount of detail necessary for user recognition
and recall. Where possible and appropriate, use perspective and dimension
(lighting and shadow) to better communicate the real-world representation, as
shown in Figure 14.35.

Graphic improved with perspective and dimension

Figure 14.35 Graphic improved with perspective and dimension

Design icon images using a light source from the upper left. To reinforce the
light source effect, use a black edge on the bottom and right and a dark gray
edge on the left and top. An alternative is to use a dark color in place of the
dark gray.

User recognition and recollection are two important factors to consider in icon
design. Recognition means that the user can identify the icon and easily
associate it with a particular object. Support user recognition by using
effective metaphors. Use real-world objects to represent abstract ideas so that
the user can draw from previous learning and experiences. Exploit the user's
knowledge of the world and allude to the familiar.

To facilitate recollection, design your icons to be simple and distinct. Apply
the icon consistently to build recognition; therefore, design your small icons
to be as similar as possible to their larger counterparts. Try to preserve their
general shape and any distinctive detail. Icons that are 48 x 48 pixels can be
rendered in 256 colors to create very realistic-looking icons, but focus on
simplicity and a careful use of color. If your software is targeted for
computers that can display only 256 colors, make sure you only use colors from
the system's standard 256-color palette. If your software is targeted for
computers configured for 65,000 or more colors, you can use any combination of
colors.

Avoid using people, stereotypes, faces, gender, or body parts as icons. This is
particularly important for an international audience, as such images may not
easily translate or could be offensive. When you must represent people or users,
depict them as generically as possible; avoid realistic depictions.

Consider how overlay images — such as a shortcut icon, an offline icon, or other
visual annotations — might affect the appearance of icons, as shown in Figure
14.36. Make sure they don't cover up the most important parts of your images.

Icon overlays and annotations

Figure 14.36 Icon overlays and annotations

One solution to avoid covering critical information is to flip your icon image
horizontally. If you do, remember to adjust the light source.

Reuse established concepts where possible. For example, if there are existing
images for illustrating objects such as documents, you may want to extend that
idea, including other details to help differentiate the image for your specific
use. However, check on copyright usage before explicitly duplicating any images.

Draw your ideas by using an icon-editing utility or pixel (bitmap) drawing
package. Drawing icons directly on the screen provides you with immediate
feedback about their appearance. It is a good idea to begin the design in black
and white. Consider color as a property enhancement. Test your images on
different backgrounds, because they may not always be visible against white or
gray backgrounds.
Icon Usage

Icons are primarily intended to represent objects with which users can interact.
Therefore, be careful in the use of icons and follow these guidelines:

    * Use an icon as the representation of an object — for example, a folder
icon in a folder's properties window.
    * Use an icon to reinforce important information — for example, a warning
icon in a message dialog box.
    * Use an icon to provide visual anchors to help users quickly navigate
through a task.

Avoid using icons in lower level dialog boxes, as this creates visual clutter.

Comment 83

[Malcolm Scott]

> I looked at the watermark icon in Linux, and I don't get how it conveys
> anything about Mozilla. Do you have to see it on Windows?

I checked the icon on Linux, and I only got the 16-colour version. (That was in
Konqueror.) I suspect you'll need to see it in Windows.

Comment 84

[Malcolm Scott]

Attachment: Demonstration of watermark base icon (PNG)

This is so people can view the watermark icon easily on Linux etc.

Note that this isn't a finished icon - I believe the idea was to put various
overlays on top of this depending on the file type.

Comment 85

[Brian 'netdragon' Bober]

Attachment: Your watermark icon but without the dino watermark and the head moved

Here is an example showing all the design style issues that Microsoft mentioned
above. I showed the application icon, but left most of the space to put in
something to identify the file type.On the right, I showed what an image file
could look like.

I like that watermark idea, but I wish the watermark would be floating to the
left instead of on the sheet itself where you could put something identifying
the image type. Problem is, that when you do that, it doesn't look right unless
fully opaque. The main thing we are trying to emphasize is the file type with
only a hint at what opens it. A watermark in the middle might obstruct too much
of the image even if it is translucent. What does it look in 256 color? (Can
you attach that?). Do we need to have a 16 color icon? It says we do above, but
that guide probably has out of date content. The only time I think a 16 color
icon would be necessary is when the user is in 256 color mode (unless the icon
uses the system color palette). How many people still use that?

I have to give you credit that the watermark idea would be good for a large
enough icon, but when its only a half inch square or less on the screen, a
watermark will just obstruct the graphics that identifies what type of file it
is.

I did use the watermark concept to make the background of the image file icon I
am attaching now blend in a bit more with the rest of the icon which has softer
colors.

Comment 86

[Jez]

> Supply icons for your application in 16-color and 256-color versions
Could I just throw in a word of warning here: you most certainly *SHOULDN'T*
supply a 256-color version of the icon.  Supply a true color image.  Why?  To
quote from Microangelo help:
"Windows does not recognize any difference between image formats that have 8-bit
color or greater when it chooses an image from an icon resource. For this reason
you should not include 256-color images and True Color images of the same size.
Windows will always treat these images equally and choose the first hi-color
image it finds."

So you may end up with a 256-color icon being displayed on a system capable of
true color if you include the 256 color icon, whereas a true color icon is
likely to degrade well automatically to 256 color, on a 256 color system.  For
this reason, supplied Windows icons should include a 16 color version (legacy
support??), true color version and a Windows XP version.

As for the rest of the debate...
To be honest, I'm still not seeing what the problem is with the red page and an
overlay to indicate the group of file type.  There really isn't much of a
standard for Windows icons; you get all sorts.  Some icons do indeed identify
the opening program via a small image in the top left hand corner of the icon. 
However, others draw this image directly onto center of the 'page' of the icon
(Paint Shop Pro), others indicate the file *type* via the overlay (see the
Windows XP defult INI icon, the cogwheel) and other still don't use a sheet of
paper at all (WinRAR, a smiley face?  a kangaroo??)

I'm afraid you Mozilla people are gonna have to accept that *there just isn't a
standard for this* so we're gonna have to decide what the best method for
identifying associated file is.

Personally, I like the 'type' overlay on the red page idea.  It has quite a few
benefits.
- Perception simplicity.  No watermark, no clutter, just a red page to clearly
identify Mozilla and an overlay to clearly identify group type.
- Image simplicity.  It can be degraded acceptably to a 16 color palette.
- Conveys application AND file classification.  Red page = Mozilla, overlay =
file classification.
- Fits in with Windows icon convention.  It's common convention to identify
associated files with a folded page and an overlay.
- Doesn't interfere with stuff the OS may overlay.  In the case of Windows, this
is the 'shortcut' arrow in the bottom right hand corner.  It won't significantly
interfere with the icon's appearance.
- Good compromise.  It contains aspects from both camps (shows application that
opens file, shows file group type) so nobody's desires are ignored.
- Why not?  It would work just fine.

Thoughts?

Comment 87

[Michael Newton]

Going back to comment 34, did anyone contact IconFactory?  It seems nothing is
happening with this bug so far but a lot of talk.  Most of the icons so far
proposed look amateurish at best.  I think (and I know that's been said far too
many times already) that if Mozilla wants to be a serious competition for IE,
and make a mark in the world it's going to have to look as professional as
possible.  And if that means paying for icons, I think it should be done.

Comment 88

[Skewer]

I agree with Jeremy's agreeing with me. I could go on and on about how
humilating it would be for us if we used anything like the watermark icon or
attachment 128798 [details] but I think that's not necessary. So icon style *should* be a
closed book; attachment 128636 [details] for HTML/XHTML, attachment 128669 [details] for
XML/DTD/RDF, and attachment 128670 [details] as a default image icon (some attachments
need work).

As for the issue of giving JPEG and PNG their own icons:

  Both of these methods are in use in a default Windows XP installation: some
  filetypes (e.g. HTML) have a logo which tell you "this will open in IE",
  whereas others (e.g. images) have icons which just tell you "this is an
  image" and give no clue as to what they'll open with.

Wrong. In a default WinXP installation there are different icons for JPEG, PNG,
GIF, and BMP as described previously, and those types are assigned to the
Windows Picture and Fax Viewer. We need to behave similar to Windows Picture and
Fax Viewer which uses separate icons for JPG, PNG, and GIF, with NO branding (in
our case, red page branding), and the overlay is a file type identifier.
Microsoft may not know how to make a standards-compliant browser but they
certainly know their own shell!

  This isn't an important enough thing to warrant the extra almost 1 meg of
  bloat

Whaaaat? 1MB if we wastefully gave every little format its own icon. I'm
suggesting exactly FIVE icons. HTML, XML, JPEG, PNG, GIF (default image).

  Going back to comment 34, did anyone contact IconFactory?  It seems nothing
  is happening with this bug so far but a lot of talk.  Most of the icons so
  far proposed look amateurish at best.  I think (and I know that's been said
  far too many times already) that if Mozilla wants to be a serious
  competition for IE, and make a mark in the world it's going to have to look
  as professional as possible.  And if that means paying for icons, I think it
  should be done.

#1, I think the icons that Jeremy and I have made so far are as good as anything
else in the WinXP OS, especially having viewed them alongside other icons.

#2, If you have that kind of money to spend, knock yourself out. There's no way
anyone at Mozilla's going to pay to have icons made when there's already been
several good ones submitted.

Comment 89

[Skewer]

I found another good example of differentiating between icons. Macromedia Flash
MX will associate .FLA files with a red f icon and .SWF files with a white f
icon. The two formats are similar but different (just as JPEG and PNG are
different; one is lossy, the other is lossless).

Comment 90

[Jez]

RE: comment #87
> Going back to comment 34, did anyone contact IconFactory?  It seems nothing is
> happening with this bug so far but a lot of talk.  Most of the icons so far
> proposed look amateurish at best.

I'm sorry, but just what do you describe as a 'professional' icon?  Something
that's been paid for??  Why should we have to pay for it?  Not wishing to sound
biased, but I think my icons are just as good as ANY document icons in Windows.
 They're simple, attractive and effective.  Icons should be just that; they
shouldn't be a visual Picasso, they're there to communicate quick, useful
information to the user.  I say sod IconFactory :-)  BTW if you wish to compare
my icons to IE's document icon, go ahead.  I'll attach it to this bug and you
see if it's any more 'professional'.  I don't think it is.

Re: comments #88 and #89
> We need to behave similar to Windows Picture and
> Fax Viewer which uses separate icons for JPG, PNG, and GIF, with NO branding
> (in our case, red page branding)

Why?  The fact that there is no branding in a Windows XP default installation is
actually quite a good indicator that no third party application has been
installed to handle those filetypes.  I see no problem with branding the icons
(as long as it's subtle branding like the red page) and, in fact, think it would
be very useful.

As for the seperate icons for JPG, PNG, GIF *sigh* well I don't agree with this,
but I won't argue against it if you insist.  You didn't reply to my comment
about there being tons of image formats OTHER than these, though; what're you
gonna do for them?  I suppose you'd propose using the 'generic' image icon -
that I'd like used for all image formats - for these?  As long as the red page
background is consistently used for all icons and the overlay is used to
indicate file type/group, filetypes associated with Mozilla will have a clear,
good-looking icon.

Comment 91

[Jez]

Sorry, forgot to reply to comment #89
> I found another good example of differentiating between icons. Macromedia Flash
> MX will associate .FLA files with a red f icon and .SWF files with a white f
> icon.

We've already found a good way of differentiating between icons with the
different overlay.  This method frankly seems inferior.  There's no picture
(overlay) to hint at what the different filetypes are, just a color of 'f'.

Comment 92

[Jez]

Attachment: The Internet Explorer document icon

Is this SO much more professional than attachment #128636 [details] ?

Comment 93

[Malcolm Scott]

> Not wishing to sound biased, but I think my icons are just as good as ANY
> document icons in Windows.

FWIW, I agree.

Comment 94

[Jez]

Attachment: Proposed design for general image icon

Here's a PNG with my proposed design for a 'general' image icon for
Mozilla-associated image files.  It's a bit average and I couldn't get it small
enough for 16x16 though, so if anyone could come up with a better one, that'd
be good.

Comment 95

[Skewer]

  As for the seperate icons for JPG, PNG, GIF *sigh* well I don't agree with
  this, but I won't argue against it if you insist.  You didn't reply to my
  comment about there being tons of image formats OTHER than these, though;
  what're you gonna do for them?  I suppose you'd propose using the 'generic'
  image icon - that I'd like used for all image formats - for these?  As long
  as the red page background is consistently used for all icons and the overlay
  is used to indicate file type/group, filetypes associated with Mozilla will
  have a clear, good-looking icon.

That's right; lesser-used formats like SVG, XBM, BMP, on the narrow chance that
they get assigned to Mozilla, can use a default image icon and be identified
using one of the less convenient methods already described. It's only really
important that the user knows the difference between JPEG, PNG, and GIF.

Attachment 128855 [details] would actually make a good PNG icon... Png, Paintbrush. JPEG
needs some kind of photo theme, so the icon should either have a photo on it
(like WPFV) or a camera overlay. I think attachment 128670 [details] should be used as the
default image icon, because it's consistent with the placeholder icon. If you
attach an ICO file of the paintbrush icon (and if possible a transparent layer
of just the paintbrush) I think I can make a 16x16 version of it.

Comment 96

[Jez]

Attachment: Preliminary paintbrush 'image' icon

> If you
> attach an ICO file of the paintbrush icon

Done, but had to move the darn paintbrush icons a couple of pixels to the right
to fit them onto the icon (piece of red paper must always stay in the same
place).

Unfortunately, because of the antialiasing effect around the handle of the
paintbrush, the Windows XP drop shadow looks terrible for that area... I'm
terrible at fixing up that kind of thing, so if you could...

Comment 97

[Jez]

Attachment: Paintbrush images

> (and if possible a transparent layer
> of just the paintbrush)

Done.  zip contains the paintbrush images with a white BG.

Comment 98

[Skewer]

Attachment: GIF/Default image icon (complete)

Comment 99

[Skewer]

Attachment: XML icon (complete)

Comment 100

[Skewer]

Attachment: Paintbrush (PNG?) icon (complete?)

I couldn't get this one to look good in 16-color no matter what I did, but the
current result is still better than if the icon was downsampled automatically
to 16 colors. I did all the 16 color versions by hand but the paintbrush handle
doesn't want to look good at all. However I did fix all the issues with poor
shadowing and got the 16x16 image to look good.

Comment 101

[Skewer]

Is there a chance these icons might look weird in 8/16/24-bit color modes? If so
I'd be interested to hear a report from someone who can test the icons in low
color (something I as an XP user don't have access to).

Comment 102

[Michael Newton]

screenshots are at http://24.85.136.193/moz

They look okay, the red page effect is lost somewhat at 8 bit, since the page is
grey, but the outline is still red.

Comment 103

[Michael Newton]

sorry, screenshots are at http://24.83.188.38/moz

(can't be bothered to pay for a static IP address, and it just changed on me
this evening!)

Comment 104

[Hanspeter Niederstrasser]

Something I am seeing in many of these icons is that the various sizes seem to
be just downsampling of the original 48x48 icon.

This invariably leads to fuzzyness at smaller sizes.  At smaller sizes, what
becomes important, the background or the foreground?  I think it is the
foreground, since that is what distinguishes the various icons from each other.
 While the background should scale at least linearly with the icon size, the
foreground should scale less dramatically.

See http://www.geocities.com/tryandguessit/mozilla/index.html for an example of
how the iconography can remain constant so that smaller versions still project
the same idea.  Naturally, at 16x16, the iconography cannot be the same size as
at 48x48, but it should predominate over the background, and may even be the
only thing left, without any background.  The new Mac OS X icons (bug 88393
comment#56) have the almost same foreground through all resolutions, but
completely lose the background at smaller sizes.  The example I list above is a
quick hack illustrating this with the icon from attachment 128911 [details].  I didn't
make a 16x16 icon because I couldn't shrink the paintbrush well enough without
the original.  The foreground tells us what the icon is all about.  It needs to
remain bold and clear always.

Comment 105

[Brian 'netdragon' Bober]

> "Windows does not recognize any difference between image formats that have 8-bit
> color or greater when it chooses an image from an icon resource. For this reason
> you should not include 256-color images and True Color images of the same size.
> Windows will always treat these images equally and choose the first hi-color
> image it finds.

I believe on Windows XPyou don't have to worry about this, while in Windows9x,
they use 256 color bitmaps by default. That's why things look so much nicer in
Windows XP. I forgot whether its the same on Win2000.

> I'm afraid you Mozilla people are gonna have to accept that *there just isn't
> a standard for this* so we're gonna have to decide what the best method for
> identifying associated file is.

The standard is what Microsoft wrote in their guide I included above. It makes
perfect sense. You could consider the red page as the identifying feature from
the application, so I guess it would work. Either that or the head on the
upper-left seem fine to me.

> We need to behave similar to Windows Picture and
> Fax Viewer which uses separate icons for JPG, PNG, and GIF, with NO branding 
> (in our case, red page branding)
Why don't we just copy their icons, so no one will know it opens in Mozilla?
Perhaps M$ will extend their license to us. The reason they have no branding is
they are the default shell icons. They don't need any branding because everyone
recognizes that's the original icons they had on the system.You can't use this
as an argument.

> Whaaaat? 1MB if we wastefully gave every little format its own icon. I'm
> suggesting exactly FIVE icons. HTML, XML, JPEG, PNG, GIF (default image).
BMP, SVG, ICO, MNG, JNG
This is totally unecessary. We could have an extension for more specific icons.

>The fact that there is no branding in a Windows XP default installation is
>actually quite a good indicator that no third party application has been
>installed to handle those filetypes.
Exactly, as I said above.

>As for the seperate icons for JPG, PNG, GIF *sigh* well I don't agree with
>this, but I won't argue against it if you insist.
I will argue against it.

I think the attached icons are good. Let's throw in the hatchet and just do some
variant on the red head or red border, and then just decide how specific we want
the icons to be. We are discussing too many things.

Comment 106

[Brian 'netdragon' Bober]

> It's only really
> important that the user knows the difference between JPEG, PNG, and GIF.

That's a matter of opinion.
I don't want extra image icons checked into the tree. We only need one, and to
make the interface extensible. We are trying to remove bloat with the new
direction of the Roadmap.

BTW:

Downsampling is OK, but you need to clean up anything that doesn't come out well
pixel by pixel.

Comment 107

[Jez]

> Downsampling is OK, but you need to clean up anything that doesn't come out well
> pixel by pixel.

Indeed, and I'm starting to think that the paintbrush icon is a bad one, because
I just can't get it to look meaningful at 16x16.  It's not the simplicity of a
paintbrush that's the problem - it's simple enough... it's the length of the
thing :-)  Because icons are nearly square, we need square(ish) pictures to go
in them.  The Mozilla head is a great example, and works well.  Maybe I should
mark my paintbrush icon as obsolete... perhaps a paint palette would be better?

Comment 108

[Skewer]

Brian: If you've forgotten what the purpose of this bug is, re-read its
description. Different shell icons to identify *EACH* associated file type. None
of the owners have marked it WONTFIX so it's safe to assume that any
side-effects to fixing this bug are worth having. So please stop regurgitating
your opposition to this bug. Besides you've already proven with your MSDN
document that we *do* need to create different icons for different formats.
We're not making icons for BMP, ICO, SVG, or anything stupid like that, and
we're not going to textually put the extension into the icon, so don't be
talking like we are.

At a bare minimum we're going to need the HTML, XML, and image icons to tell
those three types apart. They're different enough that it's very easy to justify
giving them their own icons. As for JPEG and PNG, it would be very bad for us to
use the same icon for them as any other image. We just need to design icons for
those two formats. As for the paintbrush, I have mixed feelings about that icon;
at 16x16 it is distinct but not recognizable. (TBH at 16x16 it looks more like a
joint than a paintbrush...) I think that one ought to be scrapped, and in the
future we should design for 16x16 and work our way up. Very few people use 48x48
icons so it doesn't mean much if an icon only looks really good at that size.

Comment 109

[Jez]

> At a bare minimum we're going to need the HTML, XML, and image icons to tell
> those three types apart.

Why different icons for HTML and XML?  XML stands for 'eXtensible Markup
Language', and is just HTML 'on drugs'.  They're too similar to warrant seperate
icons.  I say leave them both with the Mozilla head, and leave users to see the
file's extension / not care that much about which of those 2 it is.

> As for the paintbrush, I have mixed feelings about that icon;
> at 16x16 it is distinct but not recognizable.

Agreed.  I'm working on a palette icon right now, and it's looking much more
promising.  Suggest that overlays for icons be roughly square in shape, so they
can be scaled down more effectively.

> in the
> future we should design for 16x16 and work our way up. Very few people use
> 48x48 icons so it doesn't mean much if an icon only looks really good at that
> size.

Because it's perfectly possible to find overlays for icons that look good at all
3 sizes, I think we should make them look good at all sizes.  It's much easier
to start with a big icon and scale down than to start small and scale up (try
adding detail to an image!!) so starting with 16x16 isn't a good idea.  Just
find overlays that can be scaled down well.

Comment 110

[Skewer]

  Why different icons for HTML and XML?  XML stands for 'eXtensible Markup
  Language', and is just HTML 'on drugs'.  They're too similar to warrant
  seperate icons.  I say leave them both with the Mozilla head, and leave
  users to see the file's extension / not care that much about which of those
  2 it is.

Sounds like you don't know what XML is. :)

XML does not normally contain any HTML tags at all. It is not at all similar to
HTML. I'd say we'd be more correct to make images use the same icon as HTML than
to make XML use the same icon as HTML.

Furthermore, bug 108513 was duped to this one and that bug was titled "Different
icons for HTML and XML files." This is wanted.

Comment 111

[Jez]

> Sounds like you don't know what XML is. :)
> XML does not normally contain any HTML tags at all. It is not at all similar to
> HTML. I'd say we'd be more correct to make images use the same icon as HTML than
> to make XML use the same icon as HTML.

OK, so 'HTML on drugs' is a bit too simple a metaphor.  However, they're both
markup languages.  They're both text documents.  They're both used to help
render information in a nicer/better laid out way.  They're both derivitaves of
the same standard (SGML).  In my opinion, they warrant the same icon; XML can be
used (and is used) to improve upon HTML, to make it easier to work with... is it
often used for much else?  If so, please tell me; i'm not the world's greatest
expert with XML, certainly.

Comment 112

[Jez]

Attachment: Windows 'blank' Mozilla icon (template)

I've made the watermark obsolete; general consensus seems to be to KISS. ;-)

Comment 113

[Brian 'netdragon' Bober]

> If you've forgotten what the purpose of this bug is, re-read its
> description. Different shell icons to identify *EACH* associated file type.
Depends on what your definition of file type is. The bug doesn't say "file
extension", it says "type". Our handling of images is poor compared to Windows
Picture and Fax Viewer or ACDSee and it doesn't warrant having all those extra
icons in the distribution for each extension when hardly anyone is going to
associate images with Mozilla. You explained why you want every extension to
have its own icon, but that doesn't seem necessary to me. 

I guess as long as you only do .png, .jpg/.jpeg, and .gif, and don't go
overboard, I won't complain because its not worth it and it follows the behavior
Windows does.

If we eventually made this extensible, then add-ons that handle other image
formats could install additional association icons.

The paintbrush icon is a good idea for GIFs because they are usually graphic
art, but perhaps we should just keep it simple and show a depiction of a picture
for jpegs, shapes for gif since its usually drawn, and I have no clue for png
since it could be both. I'd also personally like it if nothing protruded from
the depiction of a document page unless its a mini application icon.

If you want the paintbrush, I'd have it stand more upright so its contained
within the page, and have it drawing a little something with some perspective.
You could use a pencil, too.. And that might be easier to depict in 16x16.

For the XML, it would look better if the <X> were moved inside of the page, and
not extending outside of it and its a bit unreadable at 16x16. Also, this would
allow you to make the document depiction larger and allow you to fit more on it.
For HTML, something like this:

______________
_______ ______
_______ |     |
_______ |     |
________ ------
_____
|    | ________
|    | ________
------ ________
_______________

That depicts text floating around images (use your imagination :-) ) would be
more appropriate than the <X>

Looking at the icons Microsoft uses, I am increasingly warming up to the idea of
just a red border since they look cleaner without a little dino head. It also
gives more room.

> Very few people use 48x48 icons so it doesn't mean much if an icon only looks
> really good at that size.

It is, because this size is what Linux uses, and we could convert the 48x48
true-color device image to the format Linux uses to keep cross-platform
consistancy. Also, as resolutions become higher, people might start using them
more often.

16x16 also needs cleaning up for all the attachments, as someone mentioned
before. Making it so that everything is contained within the red page will give
you 76 more pixels to work with inside the document image an image with only 256
pixels. Of course, we would have to leave a couple pixel columns open so it
wouldn't look like the page is square. I believe that for consistancy, if one
icon has everything contained within the document page depiction, it should be
that way for every icon.

I also noticed that the standard device images you don't normally see (I assume
16 color) have grey and white for the page background. Can't we use a lighter
red like we did in the true-color images? You just need to change the palette
for that one color.

I also think it would be a good idea to come up with a common naming scheme for
the icons. Something like imgGIF.ico, imgPNG.ico, imgDefault.ico, docXML.ico,
docHTML.ico. This allows the icon names to reflect that its an image of type
GIF, image of type PNG, document of type XML, etc. It also means we have
consistancy.

> Why different icons for HTML and XML? 
They are signifiicantly different. In fact, XUL, XHTML, and RDF files are all
XML files with different namespaces. If we are going to do different icons for
images, we should do different icons for those, also. We also need a default
document icon (perhaps just a page with text).
>They're both derivitaves of the same standard (SGML). 
That's a bit misleading. XML isn't a presentation language. HTML is to SGML as
XUL is to XML. XUL's icon would be something graphical, while RDF would look
better just as lines of text. The <X> is appropriate for XML because its just a
language with no real presentation.

>Because it's perfectly possible to find overlays for icons that look good at
>all 3 sizes

Agreed. It just takes time, patience, and artistic ability. I filed a new bug
for creating an art/graphics component within the Marketing product (bug 214688)
so we can hopefully get some graphic artists to head that component and make
decisions about Mozilla graphics.

Comment 114

[Brian 'netdragon' Bober]

Attachment: Windows blank template. Same as above except with new 16 color images

The 16 color icons should have had a light red and not grey background.

We need to also include the template icon in the source (but not package it in
the distributions). That wasn't done for giovanni's icons, but it should have.

Comment 115

[Jez]

> I'd also personally like it if nothing protruded from
> the depiction of a document page unless its a mini application icon.

No no no, we must have the protrusion! :-)  It gives the icon far more character
and looks nicer.

> Looking at the icons Microsoft uses, I am increasingly warming up to the idea
> of just a red border since they look cleaner without a little dino head. It
> also gives more room.

Dunno what you mean by 'without a little dino head'... that overlaid dino head
is the proposed icon for 'standard' Mozilla filetypes.

> It is, because this size is what Linux uses, and we could convert the 48x48
> true-color device image to the format Linux uses to keep cross-platform
> consistancy. Also, as resolutions become higher, people might start using them
> more often.

Agreed.

> 16x16 also needs cleaning up for all the attachments, as someone mentioned
> before.

I think they look fine.

> Making it so that everything is contained within the red page will give
> you 76 more pixels to work with inside the document image

Eh??  The protruded overlay gives you exactly the same number of pixels to work
with.  And we have plenty to work with as it is.  Keep the protrusion, I say.

> I believe that for consistancy, if one
> icon has everything contained within the document page depiction, it should be
> that way for every icon.

And I believe that, for consistency, all overlays should be slightly protruded,
as it looks nicer. :-P

> I also noticed that the standard device images you don't normally see (I
> assume 16 color) have grey and white for the page background. Can't we use a
> lighter red like we did in the true-color images? You just need to change the
> palette for that one color.

Um, no!  The whole point of the 16 color palette I used is that it's safe; it
will display perfectly, as intended, in 16 color mode, which has a *fixed*
palette.  You can't reliably change a palette color in 16 color mode.  Leave it
alone, it looks fine.

Re: comment 114
> Created an attachment (id=128979)
> Windows blank template. Same as above except with new 16 color images
> The 16 color icons should have had a light red and not grey background.

How rude.  You've marked my attachment as obsolete, without so much as a word to
consult me.  Your changed 16 color palette is NOT safe, so please remove your
attachment and re-instate mine.  If you're going to change the 16 color icon:
1) Ask me first before you mark my attachment obsolete.
2) Use a safe 16 color palette.

Thank you.

Comment 116

[Skewer]

Attachment fixed. Do NOT obsolete others' attachments unless you know what
you're doing. (Sidenote, I've obsoleted Brian's icon because the 16-color
pictures are corrupt.)

Comment 117

[Brian 'netdragon' Bober]

Attachment: Template icon without grey for 16 color

> Um, no!  The whole point of the 16 color palette I used is that it's safe; it

> will display perfectly, as intended, in 16 color mode, which has a *fixed*
> palette. 
My mistake. Then something has to be done about the grey. It doesn't look
right. Perhaps we could use the purple color. Attaching and not marking
obsolete.

>How rude.  You've marked my attachment as obsolete, without so much as a word
>to consult me.
You marked mine obsolete without consulting me afterwards to get even? Seems a
bit hypocritical. :-)

Comment 118

[Brian 'netdragon' Bober]

Oh, skewer did it. Still, I did not give him permission.

My reasoning for obsoleting was it had an grey background that doesn't match
with the true-color icons. Even the purple I just attached is better. My
reasoning was sound, my replacment had a flaw.

Comment 119

[Jez]

Attachment: Windows 'HTML/general/misc' Mozilla icon

Seeing as how people don't seem to want this icon, but a seperate one, for XML
files...

Comment 120

[Jez]

> My reasoning for obsoleting was it had an grey background that doesn't match
> with the true-color icons. Even the purple I just attached is better.

Eugh.  No, it looks terrible.  The point of the light grey pixels was to
illustrate the light source from the top left hand corner.  It does that pretty
damn well.  Just because it doesn't match the orangey color of the true color
icons is not a fatal flaw.  Many 16 color icons will lose subtle colors in order
to look reasonable.  The red border on the 16 color icon alone is enough to
identify the icon as a Mozilla icon.  It doesn't need the fade to be orangey;
with 16 colors, our standards are lowered.  It needs there to be a fade that
doesn't look like someone just vomited on the piece of paper.

Comment 121

[Skewer]

  My mistake. Then something has to be done about the grey. It doesn't look
  right. Perhaps we could use the purple color. Attaching and not marking
  obsolete.

Ack... Eyes bleeding... Stomach upturned... I don't think so.

  My reasoning for obsoleting was it had an grey background that doesn't match
  with the true-color icons. Even the purple I just attached is better. My
  reasoning was sound, my replacment had a flaw.

You don't obsolete someone else's attachment over design issues. Only good
reason to obsolete someone else's attachment is if it is corrupt (my reason).

Comment 122

[Brian 'netdragon' Bober]

Attachment: Jeremy's icon with the grey on 16 color replaced with purple

I did the same thing here, replacing the grey with purple (system color).

Comment 123

[Brian 'netdragon' Bober]

Comment on attachment 128984 [details]
Template icon without grey for 16 color

I liked the HTML icon. Having the dino head there will be useful for people who
have no idea what an HTML file is (probably 50% of Windows users).

Sorry about having to change the MIME types on these two attachments.

Comment 124

[Skewer]

Eep, make it stop!

Is there any less cruel and unusual way to punish 16-color users than bombarding
them with a sea of clashing fuchsia?

Comment 125

[Brian 'netdragon' Bober]

Attachment: XUL icon

Yeah, I guess that was a pretty feeble attempt to make 16 colors look good.

Here is an XUL icon. I chose the cursor over a button (Firebird's back button)
to signify that its a filetype used to create the layout for an application.
The True Color (XP) image I had a little trouble with because when I was
pasting in it, it was messing up, but I figured it out. I copied the regular
true colors, and then did the alpha pixels around the body. Took a while :-/

Comment 126

[Brian 'netdragon' Bober]

Attachment: XUL icon again

Found a floating icon in the image.

I think that PNG icon that was attached with the paintbrush is pretty good
looking and is fine to use. If we use it, all we need now is a jpg icon.

Comment 127

[Skewer]

Does XUL need its own filetype? When is XUL ever used except by Mozilla developers?

Comment 128

[Brian 'netdragon' Bober]

The development community is pretty large. XUL files are rarely actually opened
in the way HTML files are, so it wouldn't make sense for them to have the same
icon as HTML. It also wouldn't make sense for them to have the same icon as XML
files because they are presentational.

Comment 129

[Jez]

> The development community is pretty large. XUL files are rarely actually opened
> in the way HTML files are, so it wouldn't make sense for them to have the same
> icon as HTML. It also wouldn't make sense for them to have the same icon as XML
> files because they are presentational.

Agreed that a seperate XUL icon would be desirable (it's significantly different
that it warrants classification in a seperate 'group', if only for the reason
that it's going to be used almost exclusively by Mozilla and Mozilla-related
programs), but the arrow pointer in the icon is a big design no-no.  You
shouldn't mimic the mouse pointer in an icon.

Comment 130

[Jez]

Attachment: Windows 'image' Mozilla icon

Here's my finished redesign of the proposed 'image' icon for Mozilla.  It uses
a palete as an overlay which I think scales down far better than the paintbrush
did.

Comment 131

[Jez]

Attachment: Windows 'image' Mozilla icon

Sorry about duplicate attachment - this one slightly improves on the 16x16, 16
color version of the icon.

Comment 132

[Brian 'netdragon' Bober]

I like that one a lot.

I'm going to have to rack my brain to come up with a way to represent a UI
design element without it having a mini mouse cursor.

Comment 133

[Brian 'netdragon' Bober]

Attachment: XUL icon

By "I like that one a lot", I meant the new default image icon in case people
aren't sure what I was talking about.

The XUL icon is hard because its hard to convey the meaning of a UI element. I
think showing an application window will best convey the meaning.

Comment 134

[Brian 'netdragon' Bober]

Here is some good news:
Windows icon images are of course similiar to BMP images with a few differences
(transparencies, multiple device images). That means they aren't a compressed
format. All of you are probably aware of this. That means that when they are
compressed for the installation program or zip file, they will be compressed. I
did some tests, and found they compress around 80-90%, or from about 30k to 4k.
That's great, and means each icon will only add about 4k to the archive as
opposed to 30k! I can't believe I didn't realize this before. That should give
us a little more freedom.

These are the icons we have:

template:                    Attachment 128977 [details] (Jeremy Morton)
.xml:                        Attachment 128906 [details] (Skewer)
.ong:                        Attachment 128911 [details] (Skewer)
.xul:                        Attachment 129024 [details] (Brian Bober)
.gif/.bmp/.ico/.svg/Default: Attachment 128905 [details] (Skewer)
.html/.xhtml/.url/General:   Attachment 128985 [details] (Jeremy Morton)

Did I miss anything?

IE Evil icon (Comparison of quality): Attachment 128838 [details]

What we need:
- Jpeg files (a depiction of a photograph would be best in my opinion)
- Do we handle .mng? If so, perhaps it should be something depicting it can be
an animation as opposed to the default image icon?

On timeless's Attachment 69906 [details], there is also listed .dtd and .rdf, etc... Since
those won't be opened directly from the shell into mozilla, we don't need them
do we?

Also, he mentioned a lock icon for the http: protocol, etc. Do we need those?
Will the shell ever be displaying that icon on a shortcut or anything?

Comment 135

[Malcolm Scott]

I believe .url should be a different icon to .html - they're very different
things. (One's a shortcut to a web address, another is a web page saved locally.)

IE uses the HTML icon with a shortcut arrow overlay for .url's; I think we
should mimic that behaviour since a .url is essentially a shortcut which happens
to point to a web address (you create the shortcut the same way, via Right-click
/ New / Shortcut).

Also to complicate matters, you can have different icons (in WinXP at least) for
different protocols of .url . Looking at attachment 69906 [details], I think we only need
icons for http:, https:, ftp: and mailto:. (And possibly news: as well? Not sure.)

Attachment 69906 [details] states that https: should not have the same icon as http:.
Windows actually has them the same, but I think having them separate is a good
idea. https: could simply be the http: icon with a small padlock overlay in the
bottom right.

mailto: could be an envelope with a shortcut arrow.

I'm not sure about ftp: - any ideas?

Comment 136

[Brian 'netdragon' Bober]

> IE uses the HTML icon with a shortcut arrow overlay for .url's

That arrow is an explorer overlay, and not built into the icon.

> https: could simply be the http: icon with a small padlock overlay in the
> bottom right.

Agreed, and we can just copy the padlock that's used in the status bar.

Comment 137

[Malcolm Scott]

> > IE uses the HTML icon with a shortcut arrow overlay for .url's
>
> That arrow is an explorer overlay, and not built into the icon.

Sorry, my mistake. (There is an icon embedded in iexplore.exe with a shortcut
arrow overlay built into the icon, but it turns out that isn't used...)

Comment 138

[Skewer]

Corrections:

There is no such format as .ong, and the old paintbrush icon needs to go away.

template:                    Attachment 128977 [details] (Jeremy Morton)
.xml:                        Attachment 128906 [details] (Skewer)
.png:                        Attachment 129014 [details] (Jeremy Morton)
.xul:                        Attachment 129024 [details] (Brian Bober)
.gif/.bmp/.ico/.svg/Default: Attachment 128905 [details] (Skewer)
.html/.xhtml/.url/General:   Attachment 128985 [details] (Jeremy Morton)

Attachment 129014 [details] is much better than the paintbrush but the larger truecolor
versions are a bit bland; maybe you could use gradient colors in each paint
splotch? It definitely works as 16x16 or 16 color.

I would suggest that the XUL icon have a gradient titlebar instead of the same
alternating pixels effect (which is only effective in 16-color), and I can do
that if it's really wanted... I just still fail to see the usefulness of
associating with XUL files.

MNG/JNG is bug 18574. Both are nice formats but I don't ever see them becoming
as common as JPEG/PNG or deserving their own icons.

DTD/RDF are both related to XML and should have an XML icon. There is still a
slight recognization problem in a folder full of XML stuff but that is much less
common than the image problem.

CSS/XSL will need their own icon someday but Mozilla doesn't take them right
now. Both are style information.

I don't see a need to create icons for protocols; if someone can demonstrate a
situation where that really matters I'd like to see it.

Comment 139

[Skewer]

Also, please let me repeat that we should NOT ever use an icon on a .ICO
association. In fact I don't think we should associate with .ICO at all. (Filed
bug 214798.)

Comment 140

[Hanspeter Niederstrasser]

> I just still fail to see the usefulness of
> associating with XUL files.

XUL is not only found within the files of the Mozilla application.  People may
have .xul files for their own uses that would be seen inside Mozilla, but not
actually be _part_ of the Mozilla application.  These are like any other
document file as far as the shell and Mozilla are concerned, and that's why they
should be associated/get an icon.

Comment 141

[Skewer]

Attachment: Retouched XUL icon with gradients

Comment 142

[Jez]

Attachment: Windows 'XUL' Mozilla icon (fixed)

Slight change of the 48x48, 16 color version of this icon - application window
overlay was one pixel too high (compared to truecolor version) - image
consistency, people!!

Please mark attachment 129031 [details] as obsolete.

Comment 143

[Jez]

> The XUL icon is hard because its hard to convey the meaning of a UI element. I
> think showing an application window will best convey the meaning.

Yep.  I like the 'application window' icon.  The one thing I would say about it
is that it's possibly to 'Windows default theme' biased... but then again, I
suppose you've got to be biased towards *something*.

> Windows icon images are of course similiar to BMP images with a few
> differences (transparencies, multiple device images). That means they aren't a
> compressed format. All of you are probably aware of this. That means that when
> they are compressed for the installation program or zip file, they will be
> compressed. I did some tests, and found they compress around 80-90%

Irrelevant.  This is no excuse to go creating hundreds of different icons.  The
best interface is to keep things as simple as possible.  We already have plenty
of 'freedom', but it should be used wisely.

> I believe .url should be a different icon to .html - they're very different
> things.

I believe it should be left to the shell to overlay an arrow onto the HTML icon,
identifying .url as the shortcut that it is.

> Looking at attachment 69906 [details], I think we only need
> icons for http:, https:, ftp: and mailto:. (And possibly news: as well? Not
> sure.)

Eh?  This is ridiculous, and is exactly the kind of icon overkill I was warning
against.  We do *not* need an icon for each and every type of protocol.  You
should kill that idea stone dead.

> Attachment 129014 [details] is much better than the paintbrush but the larger truecolor
> versions are a bit bland; maybe you could use gradient colors in each paint
> splotch?

Nah, I think it looks fine as it is.  I actually prefer the larger icons, I
think they look great.  Not everything has to have a gradient fill :-)

By the way, Skewer, I hope you don't mind that I slightly altered your XUL icon
(by 2 rows of pixels ;-); I think you should mark yours obsolete as the 48x48,
16 color version had the application window in slightly the wrong place.  Apart
from that, seems like a good icon.

Comment 144

[Malcolm Scott]

> Eh?  This is ridiculous, and is exactly the kind of icon overkill I was warning
> against.  We do *not* need an icon for each and every type of protocol.  You
> should kill that idea stone dead.

So are you suggesting we use the HTML icon even for mailto: links? That sounds a
bit misleading to me, considering it doesn't even open in a browser window...

Comment 145

[Jez]

> So are you suggesting we use the HTML icon even for mailto: links? That sounds a
> bit misleading to me, considering it doesn't even open in a browser window...

I'm suggesting we use the general Mozilla icon, ie. the Mozilla head, for these
protocol links, with (preferably) an OS-created overlay arrow to indicate a link
file.  As the Mozilla head is more general than a specific HTML icon, I think
this would be quite sufficient.

Comment 146

[Brian 'netdragon' Bober]

.ong was a typo. Look at what key is next to the right of o :-)

Comment 147

[Brian 'netdragon' Bober]

Comment on attachment 129024 [details]
XUL icon

> I would suggest that the XUL icon have a gradient titlebar instead of the same
> alternating pixels effect (which is only effective in 16-color), and I can do
> that if it's really wanted..

Thanks. It looks much better.



By the way, what .ico editors are you using? I'm using snico, but its a bit
buggy, and images often get corrupted when copying and you can't copy from True
Color to True Color (XP)

> DTD/RDF are both related to XML and should have an XML icon. There is still a
>slight recognization problem in a folder full of XML stuff but that is much >less common than the image problem.

Agreed, and I could be wrong, but I don't think people would associate DTD with
RDF with Mozilla since they aren't really presentational documents on their
own. People are more likely to associate them with notepad or something. On the
other hand, for developers, an association with XUL would make sense because
then they could just double-click it to see it.

> I don't see a need to create icons for protocols; if someone can demonstrate a
> situation where that really matters I'd like to see it.
Someone mentioned about .url files, though I really think this is stretching
it, even the lock. Isn't there also a chance that an https:// site would have a
failed certificate and not recieve the lock in the status bar? Perhaps putting
the lock on the icon would give them a false sense of security.

>Also, please let me repeat that we should NOT ever use an icon on a .ICO
>association. In fact I don't think we should associate with .ICO at all. (Filed
>bug 214798.)
Lol, thinking about it now that would screw things up for people cause they
wouldn't see the icon. Personally, I think it would be better to use a shell
extension that adds "View in Mozilla" to the context menu as opposed to doing a
full association.

> Irrelevant.  This is no excuse to go creating hundreds of different icons.  
> The best interface is to keep things as simple as possible.  We already have 
> plenty of 'freedom', but it should be used wisely.

Definately, but at least we don't have to worry about one extra icon when half
the people want it. Probably its best for us to talk about whether we need an
icon before someone wastes their time doing it and are dissappointed. Since its
an open source project, having your work included is most of the gratification
people get. We definately still need a .jpg icon.

> Eh?  This is ridiculous, and is exactly the kind of icon overkill I was 
> warning against.  We do *not* need an icon for each and every type of 
> protocol.  You should kill that idea stone dead.

Adding protocol icons is something I don't think we should really think about
unless drivers request it.

>> Attachment 129014 [details] is much better than the paintbrush but the larger truecolor
>> versions are a bit bland; maybe you could use gradient colors in each paint
>> splotch?
>
>Nah, I think it looks fine as it is.  I actually prefer the larger icons, I
>think they look great.  Not everything has to have a gradient fill :-)

Someone could feel free to put a new one that has gradient that we can compare
if they really want it, but I don't blame Jeremy for not wanting to do it
himself if he doesn't feel its necessary and I agree its plenty usable the way
it is.


So... After all the icons are ready, who is going to write the code? I hope no
one is expecting me to do it, because I was never planning to, and have higher
priority things I'm working on. I will scrounge up the relevant portions of the
tree.

Comment 148

[Brian 'netdragon' Bober]

On a quick glance, this is what I noticed:

http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooks.cpp#102

102     jpg(   jpgExts,  "MozillaJPEG",  "JPEG Image",           "jpegfile",
"image-file.ico"),
111     xul(   xulExts,  "MozillaXUL",   "Mozilla XUL Document", "",        
"doc-file.ico");

Icons are in: 
Make sure to name them all the same way, such as png-file.ico, template-file.ico
or xul-file.ico

Fixing this looks simple enough. Make sure to add the template icon to the
source (for future file types), but make sure its not added to distribution. Its
only there for developers.

I don't see .url file in that list.

Don't worry about making it extendable right now (bug 214174). This is such a
minor patch, I don't think it really matters.

Skewer:

ico(   icoExts,  "MozillaICO",   "Icon",                 "icofile", 
"image-file.ico"),

That doesn't look good. It seems as though it will override being able to see
the .ico file. I associated Mozilla with .ico files, and sure enough the dino
head replaced the icos:

The interesting thing is that these icons don't exist. I searched the tree on my
disk, and even looked for a reference on LXR. So what's the deal?

http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooksUtil.cpp#737
It looks in [chrome dir]\icons\default, checks to see if the icon exists and it
doesn't, so it defaults to thisApplication() + NS_LITERAL_CSTRING( ",0" );
http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooksUtil.cpp#732


To check that, I placed an icon in that directory and renamed it doc-file.ico,
and sure enough, it worked!!! That means you'll want to place the icons in
xpfe/bootstrap/icons/windows and change
http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/packages-win

skewer:
I made an ico called image-file.ico in the [chrome]/icons/default dir, it
replaced icon files' image with that. Bad bad.

Comment 149

[Brian 'netdragon' Bober]

Icons are in: 

should read:

Icons are in: xpfe/bootstrap/icons/windows
http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/icons/windows/

They won't be packaged automatically, you have to add them to packages-win.

Whoever wants to nail this, you can hack in support for .url files, but it might
not be easy. 


This bug could be added to the bug labeled something like: "[Meta] Easy bugfixes
for beginner developers" but I can't find that bug but know it exists. I'd throw
together a quick patch, but a patch is often not as quick as you think it will
be and my tree is a mess because I'm reorganizing my computer hard drives and stuff.

If no one here wants to write the patch, we can post a message on Mozillazine
Forums that there is an easy bug to fix for a beginner.

Comment 150

[Skewer]

JM: Yes, the fixed version is better. The off-by-a-pixel goof was in the
original icon, and I fixed the inconsistency between truecolor and XP color but
missed 16 color.

Regarding icons for protocols, when does the shell ever display an icon for a
protocol? I don't see the point in making icons for protocols if they aren't
ever displayed.

Let's not worry about the ICO format right now; hopefully bug 214798 will get
that oddity removed from Mozilla.

As for the patch, I'm experienced with C++ but not Mozilla, but I'm going to see
if there's anything I can do.

Is there a bug to add .URL support? If so that would be an appropriate place to
discuss supporting that.

Comment 151

[Brian 'netdragon' Bober]

skewer: 
This is as simple as you can get, just grab a tree from FTP, extract it, and
then build it. Modify the icon names, and then packages-win, and then rebuild.
Test and then cvs diff -u.

I wouldn't worry about the .url support right now. We can file new bugs (if they
don't exist) once all the preliminary stuff is done.

If you run into any problems, email me. I'm going to be at work a lot the next 4
days, but you'll get a response back in less than 1 day I imagine. I've actually
dealt with adding icons before, so this is not really anything new to me except
for hooking up the code which just looks like changing the icon names in the c++
file. I hope I didn't miss anything. If it doesn't work, or the icons don't
appear in the [chrome]/icons/default dir when you put them in packages-win then
let me know if you can't figure out why, but I believe it will work.

We might want to find mkaply to do the OS/2 side of this later.

Comment 152

[Brian 'netdragon' Bober]

skewer: http://www.mozilla.org/build/win32.html

Comment 153

[Alex Hosking]

I don't know what would of made this bug get so crazy, but my inbox has had
enough of it!!

Comment 154

[Skewer]

  I don't know what would of made this bug get so crazy, but my inbox has had
  enough of it!!

It's called progress... I guess that's an unusual thing here at Bugzilla. ;)

Brian: I can't currently build Mozilla because of bug 209664. Some idiot
hardcoded "cl" into the build script disobeying my GCC config. So someone else
will have to patch this unless that bug gets fixed.

Also, in the case of ICO files... I really think the format should be removed
entirely but it's actually very simple to retain the icon... this is what is
currently registered:

[HKEY_CLASSES_ROOT\icofile\DefaultIcon]
@="%1"
"PictureID"="0"

However ICO still ought to be removed entirely, and I would sooner patch bug
214798 than fix the associated icon.

Comment 155

[Brian 'netdragon' Bober]

I'd also like mozilla to give them the option to put in a context menu item 
for all assocations if they don't want to override the application for double 
click.


I don't think the .ico handling really hurts anything except embarassing us a 
little for not showing all the device icos, overriding the way they look in 
the shell, etc - it can be reversed by deassociating it.

[HKEY_CLASSES_ROOT\icofile\DefaultIcon]
@="%1"
"PictureID"="0"

This should be part of the patch for this bug.

Comment 156

[Skewer]

  I'd also like mozilla to give them the option to put in a context menu item
  for all assocations if they don't want to override the application for double
  click.

Already does this - just point to Open With. Anything beyond would be silly.

  I don't think the .ico handling really hurts anything except embarassing us
  a little for not showing all the device icos, overriding the way they look
  in the shell, etc - it can be reversed by deassociating it.
  This should be part of the patch for this bug.

If you want the ICO support you can patch it--I certainly won't waste any time
with it. ICO association in Mozilla is just stupid. My plan, if I can get this
to build, is to use the default image icon.

Also... we still need a JPEG icon. Something photography-related would be good.

Comment 157

[Jez]

Attachment: Jez's Mozilla Icon Compendium

Added a redirector to my icon compendium.  This should help as a bit of a
reference to anyone patching this bug.

Comment 158

[Malcolm Scott]

A nit to pick about the icons with alpha shadows and overlays: in other Windows
icons (I'm looking specifically at WinZip's, Microsoft Office's and Windows
Media Player's, at both 32x32 and 48x48), the overlay either generates no
shadow, or generates a shadow on top of the page. The general effect is supposed
to be that the overlay is floating above the page.

A few of the icons here don't do that - the overlay seems to be on the same
level as the page. This happens on the icons for .HTML, .PNG and .XUL. (.XML and
.GIF are fine since the overlay generates no shadow.)

Comment 159

[Jez]

> the overlay either generates no
> shadow, or generates a shadow on top of the page. The general effect is supposed
> to be that the overlay is floating above the page.

Ah yes, good observation.

I actually prefer the drop shadow to eminate as if the page and overlay are at
the same level.  Just think it looks a bit nicer.  2 shadows seem like overkill.
 But either the XML icon, or all the others need to be amended to get the
shadows normalized.

Comment 160

[Brian 'netdragon' Bober]

http://www.game-point.net/misc/compendium/index.htm

Nice page, but can you also link to this bug at the top? Some people don't 
know about the =view -> =edit trick on attachments to see the bug it belongs 
to.

Comment 161

[Brian 'netdragon' Bober]

skewer: So its possible for us to, when the user asks, insert something into the
Open With: menu?

Comment 162

[Jez]

> Nice page, but can you also link to this bug at the top?

OK, but who would be accessing the page without coming to this one first?  I was
under the assumption that people would know about this bug before viewing the page.

Comment 163

[Robert Accettura [:raccettura]]

I like the work being done... but I don't think the proposed icons will look
very attractive in OS X, or any OS that does/will use hi-rez icons.  Even if
they are rendered hi-rez... they will look pretty bland and odd.

I'm no artist unfortunately.  But I hope someone keeps in mind where icons are
going.

For example.  See what Mac OS X icons are capable of looking like:
http://www.iconfactory.com/Preview.asp?type=show&id=167

Quite fancy, complex, and photo-realistic.

Some OS X MS Office Icons:
http://design.iconfactory.com/pages/macicon/office.html

Some Windows Icons:
http://design.iconfactory.com/pages/winicon/neighbour.html

Those look good on any OS, and at Hi Rez.

I like the concepts of the proposed icons.  Clean easy look.  But I don't see
them looking good on all systems.  



Secondly.  I'm personally in favor of the file format being on the icon:  XML,
HTML, GIF, JPG.  

Some OS's hide the file type by default.  So seeing an image icon... and having
no idea what format it is.. can be cumbersome.  Especially for inexperienced
users (end users is now the focus).  

So my suggestion would be to cleanly squeeze the file name into the icon. 
Perhaps like PhotoShop does (in that bar).  So that a user can tell quickly. 
THIS IS A GIF.  THIS IS A JPEG.


The XUL one though, seems like no matter what... is platform specific.  For OS X
it should show an OSX window.  But for windows... it's a great idea!

Just my $.02

Comment 164

[Jez]

Attachment: Windows 'script' Mozilla icon

Here's a proposed icon for use with script files associated with Mozilla. 
Please, touch it up if you think you can make it look any better.

Comment 165

[Jez]

> I like the work being done... but I don't think the proposed icons will look
> very attractive in OS X, or any OS that does/will use hi-rez icons.  Even if
> they are rendered hi-rez... they will look pretty bland and odd.

That's why I specifically mark my icons as Windows icons.  I think they'd be
pretty portable to Linux, though.

> Some OS X MS Office Icons:
> http://design.iconfactory.com/pages/macicon/office.html

My God, they call those ICONS??  I don't want an icon that takes up half my
screen!  What's the point?  True, different icons would indeed need to be
designed if someone wanted to view them at 500x500 :-)  Does anyone actually
browse with those things?

> Those look good on any OS, and at Hi Rez.

Oh?  Try displaying them as a 16x16 icon.  They wouldn't look good in my file
browser.

> Secondly.  I'm personally in favor of the file format being on the icon:  XML,
> HTML, GIF, JPG.

Then you're in the minority.  It's a terrible idea.  If the OS is hiding the
file format, it's the OS's fault, not ours.  An icon isn't there to replace that
task.

Comment 166

[Skewer]

  the overlay either generates no shadow, or generates a shadow on top of the
  page. The general effect is supposed to be that the overlay is floating
  above the page.

I can agree with that but it would be difficult to add that effect to the icons
at this point, since many of them were hand-made on a single layer. If anyone
wants to try to add the shadows to these icons they can try.

  I actually prefer the drop shadow to eminate as if the page and overlay are
  at the same level.  Just think it looks a bit nicer.  2 shadows seem like
  overkill. But either the XML icon, or all the others need to be amended to
  get the shadows normalized.

I can definitely say that adding a shadow under the <x> would look horrible.
That <x> should be left as flat and nondimensional as it is. Also the image icon
would look better as-is because it's not even so much of an overlay as objects
on the page. The others could use a drop shadow on the page, but if nobody wants
to do the work it's not a major issue. Probably the only way to get a drop
shadow on the middle of these icons is to do it by hand.

  I like the work being done... but I don't think the proposed icons will
  look very attractive in OS X, or any OS that does/will use hi-rez icons.
  Even if they are rendered hi-rez... they will look pretty bland and odd.

Do people really use icons that are that big? Seems like at any resolution below
Super-Duper-Ultra-XGA you wouldn't be able to fit a folder of 30 document files
onto the screen with icons that large. But regardless, the icons that are being
done right now are for Windows only (.ICO format). I suggest that anyone making
icons for different OSes should make the icons appropriate for the shell.

  So my suggestion would be to cleanly squeeze the file name into the icon.
  Perhaps like PhotoShop does (in that bar).  So that a user can tell quickly.
  THIS IS A GIF.  THIS IS A JPEG.

For the dozenth time, that behavior is incorrect. The filetype may vary from the
extension. The extension may vary from the filetype. Text causes localization
issues. And it's almost impossible to read text that's imprinted on an icon.

Comment 167

[Skewer]

Attachment: XUL icon w/ better shadow

On second thought...

Hand edited. This may be simpler than I thought.

Comment 168

[Skewer]

Attachment: HTML icon w/ shadow

Comment 169

[Skewer]

Attachment: PNG icon w/ shadow

Comment 170

[Skewer]

Attachment: Script icon w/ shadow

Comment 171

[Skewer]

  The XUL one though, seems like no matter what... is platform specific.
  For OS X it should show an OSX window.  But for windows... it's a great idea!

Actually, neither Windows nor Mac really uses windows that look like that
anymore, so it's generic and historic enough (especially with the gradients)
that it isn't platform specific. It looks to me like an old Mac/Win98 desktop
window.

Comment 172

[Brian 'netdragon' Bober]

>Some OS's hide the file type by default.  So seeing an image icon... and having
>no idea what format it is.. can be cumbersome.  Especially for inexperienced
>users (end users is now the focus). 

We shouldn't support an OS doing that. It's something Macintosh started to be
"cool" and its a stupid idea and an incredible security risk. I can make an
executable that looks like an image file and contains da bomb virus. If you
don't have extensions visible, you will run an executable with no warning its
not a document. Microsoft says you aren't supposed to put text in your icons. I
don't know if "JPG" and "GIF" constitute text and I would argue no since they
were talking about localizations, but we decided we weren't going to do this
because it will look unattractive.

>I'm no artist unfortunately.  But I hope someone keeps in mind where icons are
>going.
You were looking at these from Explorer and not within the browser, right?
Anyway, no reason for us to go overboard at this time. These icons look just as
good as pretty much any other icons I have seen on my Windows system. If they
are not usable on Mac, then we can have someone on Mac make icons for it. They
should be fine for Linux. Eventually, as 16x16 is phased out for icons because
resolutions become too much, we can cross that road. As of yet, you still have
to expect some people to be running 640x480.

Anyway, I don't think these should be expected to be usable exactly as-is
cross-platform. For instance, the XUL icon could probably use a couple changes
to the title area for Linux and Mac, if you are going to even use it for OS X.
As far as my knowledge on Mac OS X goes, you can't use your standard user
interface on it anyway because they have a whole different way of doing things.

>The XUL one though, seems like no matter what... is platform specific.  For OS
>X it should show an OSX window.  But for windows... it's a great idea!

That can be done. All it takes is editing the image to replace the 

>Here's a proposed icon for use with script files associated with Mozilla. 
>Please, touch it up if you think you can make it look any better.
Its a bit hard to make out the wheel on 16x16, but I'm too lazy atm to touch it
up :-)

>Actually, neither Windows nor Mac really uses windows that look like that
>anymore, so it's generic and historic enough (especially with the gradients)
>that it isn't platform specific. It looks to me like an old Mac/Win98 desktop
>window.
True, and it also looks like older Linux Window Manager themes.

>HTML icon w/ shadow
>PNG icon w/ shadow
>Script icon w/ shadow

Nice. I'll do the jpg icon since no one seems to want to do it.

Comment 173

[Brian 'netdragon' Bober]

Jez (do you want us to call you that?): Thanks for putting a link to the bug on
the page. There was a chance that a spider like google might get your page...
All it would take is one link in the newsgroups etc from outside of Bugzilla.
You'd be surprised at how I've had pages I wasn't intending to get spidered or
even known about except by a couple people and somehow they wound up in search
engines.

Robert: You have some valid points, and I think that different icons for OS X
would be a good idea, but probably should be done by someone with experience
with that operating system. As for Linux and Windows, we will have to keep our
eyes open. We can guess that once 1280x1024 becomes the lowest res anyone has,
that 16x16 icons will not be a concern. I imagine that soon enough we will have
to worry about 64x64 in Windows. Linux might eventually look more like OS X. For
icons, trying to speculate on this seems like a waste of time when one can be
made in a few hours or less.

Comment 174

[Brian 'netdragon' Bober]

Few hours or less each.

Sorry about another comment, i would have said the above when I finished the
jpeg icon, but I just noticed something:


Jez: Your page is serving .ico files as plain text.

Comment 175

[Jez]

I hate to say it, but the icons where the overlays have shadows are growing on
me.  However, the shadows should only be used in the Windows XP version, and
must be consistent with the main Windows XP shadow.  The shadows that you have
added, Skewer, aren't quite the same as the alpha shadows, and they look a bit
weird.  I might have a go at 'normalising' all the shadows tomorrow; I'll let
you know how I get on.

In case you're interested, the alpha shadow that Microangelo generates for a
Windows XP icon seems to be almost identical to these 'drop shadow' settings in
Paint Shop Pro:
Vertical = 1
Horizontal = 1
Opacity = 70
Blur = 2

> Jez: Your page is serving .ico files as plain text.

Hmm, weird.  'Save link target as...' should still work.  I'll try to find out
why it's not serving them as icons, though.

Comment 176

[Brian 'netdragon' Bober]

I have a question: What ico editors you guys use? I've been using snico editor,
but its so buggy I want to switch. It just saved my jpeg image with all the
pixels white, so i lost it. I need a good freeware editor that allows all the
features we use in these ico files and also copying and pasting from the windows
clipboard with transparencies.

Comment 177

[Skewer]

Test post -- receiving "no data" errors?

Comment 178

[Skewer]

  I can make an executable that looks like an image file and contains da
  bomb virus. If you don't have extensions visible, you will run an executable
  with no warning its not a document.

Since Mozilla is connecting to the internet, we just need to be sure that all
files obtained over the internet are displayed with the extension (and
appropriate security warnings for executables, similar to IE6) long enough for
the person to see it when downloading. Once the file is on a local drive the
risk of an unexpected virus is much lower, and doesn't really make it worth the
extra clutter of extensions in a situation of a folder full of trusted files.
Also it becomes very hard to fool people if icons are creatively designed; if
they all look like app boxes with a Windows logo inside it becomes much easier
to fool someone this way. I dare anyone to successfully deploy a virus with the
new Mozilla HTML icon on it!

Comment 179

[Skewer]

  As for Linux and Windows, we will have to keep our eyes open. We can guess
  that once 1280x1024 becomes the lowest res anyone has, that 16x16 icons will
  not be a concern. I imagine that soon enough we will have to worry about
  64x64 in Windows. Linux might eventually look more like OS X. For icons,
  trying to speculate on this seems like a waste of time when one can be made
  in a few hours or less.

If I may make a prediction, I think the average resolution won't go much higher
than 1024x768 unless there are MAJOR enhancements in scalability (of text,
applications, graphics, etc.). Because while monitors can be built to as high a
resolution as you want, the human eye stays the same. I have trouble with
resolutions higher than XGA. But this is very offtopic so I'll go on.


  I hate to say it, but the icons where the overlays have shadows are growing
  on me.  However, the shadows should only be used in the Windows XP version,
  and must be consistent with the main Windows XP shadow.  The shadows that you
  have added, Skewer, aren't quite the same as the alpha shadows, and they look
  a bit weird.  I might have a go at 'normalising' all the shadows tomorrow;
  I'll let you know how I get on.

I think XUL and HTML are fine, but maybe there's too much shadow on the PNG one.
I'll upload a tweaked version. Script looks sorta-ok and we won't be using that
one yet anyway.

BTW, I'm using Axialis IconWorkshop. It's not exactly freeware but it's a timed
trial. (Time-limit trial software is almost as stupid as open-source programs
with spyware in them. Limewire, anyone?) The drop shadow in Axialis is not
consistent with the ones JM's been using so I've been copying the shadows from
the template wherever possible.

Comment 180

[Skewer]

[removed to see if that stops the error]

AddType image/x-icon ico

Apache doesn't know what an ico file is yet.

Comment 181

[Skewer]

If I put this word:

htaccess

with a . in front of it Bugzilla returns a "no data" error... but that's the
file you need to put that AddType line in.

Comment 182

[Skewer]

JM: [.]htaccess is a Bugzilla Dirty Word... remove the brackets. Create a file
with that name in your topmost folder and add the AddType line as it appears
above to correct your ICO problem.

Bug 214979 filed.

Comment 183

[Skewer]

Attachment: PNG icon w/ better shadow

Comment 184

[Skewer]

I'm sorry about all that spam... I fixed the problem.

JM: Once again all in one piece now...

Put a .htaccess file in your topmost directory (or add to it if it exists) and
add this:

AddType image/x-icon ico

That will associate the correct MIME type with ICO files.


Is the new PNG icon good enough?

Comment 185

[Brian 'netdragon' Bober]

>Since Mozilla is connecting to the internet, we just need to be sure that all
>files obtained over the internet are displayed with the extension (and
>appropriate security warnings for executables, similar to IE6) long enough for
>the person to see it when downloading.

Its a matter of principle to me. We can't police every application, so we
shouldn't support such stupid behavior. How do we know every application is
careful about what users download?

I tried to trick Axialis by setting my date to 2004 then setting it back to
2003. I guess that trick doesn't work on shareware apps anymore. Now I have to
purge all its reg entries remaining after the uninstall and figure out what is
telling it every time I open it that the time ran out.

Comment 186

[Brian 'netdragon' Bober]

I bought it. They are nice and offer free upgrades. I don't like companies 
that don't.

Comment 187

[Jez]

I hate to complain, but people having been posting *ridiculous* numbers of
unnecessary comments here.  Skewer, you really ought to have e-mailed me that
stuff.  Brian, your buying of that program is not cause for posting in this bug.
 Sorry, but it's just that, especially as this bug is already massive, let's try
to minimize the number of posts?  I'll personally just update the icons in my
compendium now instead of posting new attachments.

Now, to get to replying:

> Created an attachment (id=129135)
> PNG icon w/ better shadow

There's no need Skewer, I'll redo all the shadows on the icons to day for
ultra-consiostency ;-)  In fact, that's the best tactic: if one person
implements all the drop shadows from scratch, from the truecolor icons (because
they're easy enough to do), they'll be 100% consistent).  This can of worms is
one of the reasons I didn't initially like the idea of the second drop shadow,
but c'est la vie.

> Put a .htaccess file in your topmost directory

I did, in fact, know about .htaccess, and was just very tired last night and had
no time to investigate the relevant command.  It's now in there and I think
you'll find the server's correctly sending image files now. :-)

Comment 188

[Jez]

Fixed some ico files that were giving a 404 error over at the icon compendium. 
Darn case-sensetive operating systems, that's continually caused me problems...

Anyway, I've come to the conclusion that the drop shadows for the overlays are a
*bad* idea.  They add unnecessary complexity, with 2 drop shadows in the image.
 More importantly, most of these overlays weren't designed to have drop shadows,
and adding drop shadows, no matter how hard to try to dirm the borders up, still
looks (frankly) ****.

So, what I've done instead, to avoid the slightly weird look of having a drop
shadow for only some of the overlay, is to remove the drop shadow *completely*
for the overlay portion of the images, in the Windows XP versions, leaving only
the red page with a drop shadow.  The updated versions are over at my
compendium.  I quite like them, see what ya think.

Comment 189

[Jez]

Looking at the remaining filetypes not yet given an icon in the 'wishlist', here
are my thoughts (you can skip the penny):

.java .class .jar .zip

These strike me as filetypes that Mozilla shouldn't be dealing with.  Are .jar
files executable Java files?  If so, maybe Mozilla could open them.  But not
.java or .class files, they should be left to an editor, and .zip should be left
to the shell or a far more competent 3rd party program.

.dtd .rdf

I have to confess not having heard of these file formats before so I looked them
up.  They both seem to be declarative types of file, holding organised data for
other files to access.  I was thinking that these might be able to be grouped in
with the XML icon, but the XML icon would need a redesign, removing the 'X' and
reflecting a more general 'data resource file' group.

.xpt .xpi

What is an eXternal Page Table??  As for X-platform installer, maybe that would
warrant an icon, but maybe the Mozilla head would do...

.snm .eml

Email files and SNM (????? Netscape Mail) would seem to warrant an icon.  I
would have thought that maybe Netscape's mail client would already have an icon
for them, though...

Comment 190

[Brian 'netdragon' Bober]

Attachment: Preliminary jpeg icon

Take a look at this... I haven't done the 16x16 yet or 4 bit images, but I need
some advice on how to make the 32x32 icon easier to see. It seems the colors or
something make it not contrast enough.

As I said, Mozilla doesn't Open .dtd files or .rdf files from explorer (unless
there is something I don't know of) so we shouldn't provide an icon for these
files types.

.xpi should probably have something indicative that its an installer program,
just like the .msi files have.

Comment 191

[Malcolm Scott]

Here's my preliminary alternative JPEG icon:

http://retrosnub.co.uk/mozicons/

(I'd already almost finished this by the time Brian submitted his version. It's
not that I don't like Brian's version - I think either his or mine could become
the final JPEG icon, although both probably need a little tweaking before
they're good enough.)

Thoughts?

Comment 192

[Jez]

> Take a look at this... I haven't done the 16x16 yet or 4 bit images, but I need
> some advice on how to make the 32x32 icon easier to see. It seems the colors or
> something make it not contrast enough.

I think you're making the overlay too complex.  Just make it a single tree,
complex-looking (so it looks nice) in 48x48, but very clearly a tree shape, so
that, when scaled down to 16x16, it's still clearly a tree shape.  Use dark
brown for the bark and dark(ish) green for the leaves so it contrasts well.  I
know the tree is a cliche, but, well, that's because it's a good idea :-)  KISS ;-)

> Here's my preliminary alternative JPEG icon:
> http://retrosnub.co.uk/mozicons/
> Thoughts?

Hmm, nice try, but it suffers from the 'too complex' syndrome, and an additional
one: it's in a box.  Let's try and keep the overlays from being
square/rectangular... a rectangle on a rectangle don't look good.  Ideally, we
could find a way of paking the XUL icon's overlay non-square/rectangular, too,
but there's certainly no need for the box in the JPEG icon.

Comment 193

[timeless]

.xpt is a typelib file, a search on mozilla.org would give info. A generic 'this
is a binary mozilla data file' icon would be good enough.

.snm/.msf are mail summary files. A generic 'this is a mozilla mail file (but
not actually a mailbox)' icon would be good.

it is possible for mozilla to be the only app capable of handling jars/zips on
windows (only applies to w9x [not wME] and wNT < wXP), the mail client can
actually expand zip files. remember that the .jar files which matter are chrome
jars.

wrt .dtd/.rdf yes, some other .xml icon could be acceptable for all three, but
not the current one.

Comment 194

[Skewer]

Attachment: Malcolm's JPEG icon w/ shadow

Comment 195

[Skewer]

I hate to disagree with everyone once again but it looks like I'm just going to
have to.

JM: If this is too much mail you can go into prefs and change your notification
settings. I personally don't receive any mail because I think it's stupid (I
just come back to check the bug if I want to see what's happening).

I actually prefer Malcolm's icon, by about 1,000x. The photo is much more
representative of a JPEG file than the cartoony trees... and I don't think it's
too "busy" or anything like that at all. Even at 16x16 it works fine. That JPEG
icon is so good, it puts the WPFV JPEG icon to shame.

I added the shadow to that icon as well... because like it or not, the drop
shadow on the icon is the *correct* behavior. All the drop shadows look just
fine to me, they don't appear to be inconsistent or anything like that. If I
ever end up patching this bug I will be using the drop shadow icons.

If I gather correctly, I think I'm hearing arguments for new icons...? So far
nothing seems to merit an extra icon beyond what's already been done.

Comment 196

[Brian 'netdragon' Bober]

I think we should go with Malcom's icon. I'm just going to add a sun to it and
make it a bit more lively and see what people think. I do agree with what Jeremy
said about the frame, but its only nitpicking and not a reason to reject the
whole icon when it could be made to look a little better. Having the tree in
there was the whole mistake I made, and having a tree by itself would be kinda
boring.

timeless: If .dtd and .rdf are simply data sources, as they are, why should we
offer an association? Unless we had a kick-butt text editor, it would make no
sense at all. Perhaps we can make the icon for the future, but for now its kinda
pointless since people are much more likely to associate it with a text editor.

AFAIK, the only time .dtd and .rdf is used is included inside another xul
document. Is there any situation someone would want to actually open that within
Mozilla? If not, no one would associate it with Mozilla and the icon wouldn't be
used. OTOH, a binary data and textual data icons wouldn't hurt because they
might come in handy in the future.

There are plenty things I don't know about wrt .rdf and .dtd, and maybe you know
a case where a user could actually open the file within Mozilla. I dragged a
.jar to Mozilla and got a "Save to disk" dialog. I dragged a .dtd and .rdf file
to Mozilla and just a blank page with an ability to view it in source. That's
because they are only data. Unless we do something actually useful with the
files, or plan on doing it in the near future, it doesn't warrant making the
icons now. Perhaps when that day comes, we could just use the "textual data" icon.

So I propose for .rdf, .dtd and any file like that, we should simply make a
"textual data" icon that could be used in the future.

I also couldn't open a .jar file within Mozilla. I know Mozilla uses them, but
Mozilla also uses .dll files. How far are we going to go?

> the mail client can actually expand zip files

Do you mean it can be opened by the user in the front end or just in the backend
for distro files? If its the front-end, then I guess we should make an archive
icon. Perhaps its a good idea anyway, because we might eventually do more with
.jar and .zip files.

>.snm/.msf are mail summary files. A generic 'this is a mozilla mail file (but
> not actually a mailbox)' icon would be good.

Some envelope image with Mozilla Mail can probably give a good starting point
for the overlay.

On attachment 69906 [details]:
>.xpi it's the same thing as a .jar file (although they currently lack signature
>files). It is Mozilla/Netscape6's version of a SmartUpdate installer package.

Should they have the same icons?

Anyway, I believe that once we have a finished .jpeg icon, binary data icon,
text/textual data icon, and mail icon, we shouldn't wait any longer to patch it.
The rest of the icons could go in a separate bug. This is my opinion, and others
are free to disagree.

> if the argument is to show what the object is, then why should we change the
>icon just because we're the new owner of the object. (this might be a straw
>man.) in this view things which have icons (.js, .htm*, .jpg, .gif) should just
>keep their current icon and we should just take ownership of the verb.

Should we extend the backend association registering function to provide a flag
that allows the user to keep the associated icons as-is even if it might not be
used immediately by the front end (with a default value of PR_FALSE)? This would
allow a user to associate with Mozilla but keep their current icons on an
extension by extension basis.

Skewer: How are you doing on the patch? I'm not going to butt in or take over
like I have a history of doing, but if you need help or feel overwhelmed just
let me know by email and we can work out something.

For now (after finishing the jpeg icon), I'll just put in the code to make the
icons not change for .ico files and post it here since you said you didn't want
to write that.

Comment 197

[Brian 'netdragon' Bober]

Attachment: jpeg icon - Malcom w/ a bit of netdragon :-) i guess i'm bored

added some contrast on transitions of mountains, water, etc. Changed frame.
Added sun and reflection. No drop shadow for overlay.

Comment 198

[Malcolm Scott]

Updated http://retrosnub.co.uk/mozicons/ to include Skewer's and netdragon's
versions of my icon.

Comments:

--> Skewer's drop shadow is inconsistent with the one in Jez's original red page
icon. It seems darker, and the corners aren't rounded.

--> I like netdragon's improvements, however it seems to destroy the 16 colour
version. E.g. the water goes grey. Compare the different 16 colour icons on my
page to see what I mean. (I pretty much redid the 16 colour versions from
scratch. You appear to have simply let your software reduce the colour depth for
you automatically.)


BTW, credit where credit's due: I got the inspiration for the picture from a
painting my Dad did many years ago, and which happens to be on the wall near my
computer :) It's somewhere in the English Lake District, although I can't
remember where.

Comment 199

[timeless]

there's a rule apple has about any files you ship/generate which your users can
see, but ignoring that here are the files that matter wrt dtds:
mathml.dtd
xhtml11.dtd

wrt rdf, there's chrome.rdf in the profile, and people have this tendency to
look at files. 

wrt zip's, mozillamail can unzip .zip files for mail users. this would qualify
as frontend.

should xpi share an icon w/ jar/zip? maybe. it depends on the icon. if it's an
installer icon then no, if it's a mozilla archive icon then that'd be an
acceptable interim icon for all three.

can dtd/rdf use a mozilla generic text icon? yes, it isn't ideal, but it'd be ok.

Comment 200

[Skewer]

Attachment 129190 [details]: Two thumbs down... without the white border it doesn't look
like a polaroid anymore and thus everything I liked about the original is gone.
Also I fail to see the benefit of adding the sun; it actually makes the icon
seem cluttered in a (frivolous) way.

I'm not sure I understand what's wrong with my drop shadow... can you
demonstrate graphically?

  Skewer: How are you doing on the patch? I'm not going to butt in or take over
  like I have a history of doing, but if you need help or feel overwhelmed just
  let me know by email and we can work out something.

It is impossible to build Mozilla without MSVC due to bug 209664. I despise MSVC
so much I wouldn't even warez it let alone purchase it. (I use Dev-C++ for all
programming.) Mozilla is supposed to build with GCC but "cl" is hardcoded into
Mozilla's makefile.

Comment 201

[Malcolm Scott]

> Attachment 129190 [details]: Two thumbs down... without the white border it doesn't
> look like a polaroid anymore and thus everything I liked about the original
> is gone.

However I like some of the improved contrast on the mountains. I'll see if I can
copy some of the contrast changes back to my original "polaroid" icon sometime.

> I'm not sure I understand what's wrong with my drop shadow... can you
> demonstrate graphically?

At first I thought it was generally darker, but I now think that's because of my
black border. Perhaps I should change the border colour. Anyway, on your shadow
the lower right corner is sharp, whereas on Jez's icon it's rounded. I think the
rounded shadow looks better.

Comment 202

[Jez]

Two thunbs down to all of the proposed JPEG icons.  They're all too
busy/complex, and I can't make out what the hell they're meant to be in the
16x16 versions.

A tree is better.

Why the hell does it need to look like a Polaroid, anyway?  JPEGs aren't
*always* used for photos, you know.  They can be used for other complex art,
like paintings, CG graphics and even company logos.

Comment 203

[Brian 'netdragon' Bober]

skewer:

Its not a polaroid, its a picture frame. I like the sun, so pffft! :-)

Malcom:

>However I like some of the improved contrast on the mountains. I'll see if I can
>copy some of the contrast changes back to my original "polaroid" icon sometime.

That's fine. I don't get why skewer doesn't like the sun, but if you like it,
use the sun too :-).

Could you also put a white to light grey gradient on the white background of the
polaroid so it shows light coming from the top left corner?

> A tree is better.

The tree all by itself is not only a cliche, and over-used, but it also could
represent other things. We'd need at least a sun and a little grass or something
with the tree.

> They can be used for other complex art,like paintings, CG graphics and even 
> company logos.
Or pr0n :-)

Comment 204

[Skewer]

I was originally planning to use a tree for PNG. Because PNG is all green and
environmentally friendly and efficient and stuff. JPEG is lossy so I don't see
it having a tree by itself... JPEG was red when IE associated with it, and now
I've got a sunset photo on it so it's still slightly red. It would be
counter-intuitive to use green because both IE/WPFV use green for non-JPEG formats.

I would be happy to just use attachment 129166 [details] as the JPEG icon, I'm pleased
with that one. The polaroid thing really works as an icon. Ultimately, the
decision will be made by whoever adds the icons in, not by who complains the
most. If it were me I would use attachment 129166 [details].

I still don't see a problem with the overlay drop shadows... I think you have to
actually imagine there being something wrong with it to notice a problem. I
don't think most people will be examining our icons all that closely. Lack of a
drop shadow, they would notice, but whether a corner is sharp or rounded... I
doubt it.

Comment 205

[Skewer]

Attachment: Many subtle improvements to JPEG icon

Comment 206

[Skewer]

Attachment: XUL icon w/ rounded shadow

Comment 207

[Jez]

Modified JPEG icon in 2 ways:

Moved 'polaroid' overlay one pixel to the right on the 32x32 version to make it
more consistently placed.

Removed that infernal second drop shadow.  I think it looks ****.

The 16x16 icon doesn't have the 'polariod' white border look, because there's no
room, making the overlay inconsistent.  This bugs me.  Ah well.

My version of the JPEG icon can be found at my compendium, URL
http://www.game-point.net/misc/compendium/index.htm

Comment 208

[Skewer]

Attachment: JPEG icon up-to-date

I found a bug in a few of my icons where my software was drawing a drop shadow
on the top left (!) of the icon. Also moved that one pic over 1px though I'm
not sure why that's needed; but this way that modification is available with
the drop shadow.

Comment 209

[Skewer]

Attachment: XUL icon up-to-date

Also note my naming scheme for the icons - this is how I originally was going
to patch it. The icon names are similar to the MIME types; that's the safest
and clearest way of naming them.

Comment 210

[Skewer]

Attachment: Broken file icon

This broken file icon has no use currently, but in the future it could
definitely be implemented for a broken/incomplete download or anything like
that.

Comment 211

[Jez]

Brian: Hmm.  The icons in chrome/icons/default do indeed seem to be in
xpfe/bootstrap/icons/windows, but they also seem to be strewn about all over the
Mozilla source tree as if a bomb had hit it :-)  Look at
mozilla/calendar/windows/icons/default, for example.  Is this just messy and the
excess icons should be removed, or is there a good reason for these dupes to be
there?

Comment 212

[Brian 'netdragon' Bober]

Firebird, Sunbird, Thunderbird, etc, I imagine.

Comment 213

[Jez]

Attachment: Patch v0.1

After some blood, sweat and tears, I think this patch actually works.  Had to
modify the Makefile in the bootstrap/ dir to allow different icons to be copied
based on the OS being built on.

This patch only adds the extra icons to chrome/ if you're building on Windows. 
The mozilla/ directory needs to be extracted to your mozilla/ sourcetree; it
contains the icons.

I strongly object to any icons with the second 'overlay' drop shadow being used
for the Mozilla-associated files, especially mine.  This patch contains the
icons without the second drop shadow, just leaving the drop shadow for the red
piece of paper.

Comment 214

[Jez]

Attachment: Patch v0.2

Arghh.... looks like my DOS-Unix file conversion program mashed some of the
newlines in the source files!  I think I fixed it now; this version of the
patch is good.

Comment 215

[Jez]

Attachment: Patch v0.2 - also removes ICO association

This patch does what v0.2 does, as well as removes the ability for the user to
associate Mozilla with .ico files in the user interface (it can still, of
course, be manually told to read .ico files) to temporarily avoid the '.ico
shell icon' problem.  If/when checked in, this patch will fix bug #214798.

Comment 216

[Jez]

Updated my icon compendium to reflect the consistent icon names I used in the
patch, eg. misc-file.ico, image-file.ico, etc.

BTW, i renamed html-file.ico to misc-file.ico because, apart from being the
default HTML icon, it should be the icon for 'miscellaneous' filetypes too, that
can't be easily classified with another icon.

Comment 217

[Brian 'netdragon' Bober]

Please submit the binary files as a zip, with the Type application/zip, and then
provide the actually text diff -u file separately as Type patch. That way
reviewers can look over the code for an initial review to clear up anything
blatantly obvious before they test it. That is how we do it.

Then please mark all the previous submissions of the patches obsolete. Thanks. 

I will be doing the review of this patch for you (but of course not the
superreview).

Comment 218

[Jez]

Attachment: Patch v0.2

Submitting patch as .diff, seperate binary files (patch icons) *required*.

Comment 219

[Jez]

Attachment: Patch v0.2 - also removes ICO association

Submitting patch as .diff, seperate binary files (patch icons) *required*.

Comment 220

[Jez]

Attachment: Patch icons

These icons are *required* to exist in the source tree before my patches are
installed because they're used by the patches.

Comment 221

[Jez]

I've applied both versions of patch v0.2 and they work fine on my build, so I'm
requesting review and super-review; perhaps a 'rubber stamp' would be more in
order for this one though?

Be nice if someone changed the status whiteboard to "Need r= and sr=; Requesting
rs=;"... how do you become 'sufficiently empowered' to change it, anyway?

Comment 222

[Brian 'netdragon' Bober]

reviews and superreviews take time because the developers are queued, so
unfortunately it could take a month before you get sr=. Hopefully not. But that
is part of the reason its a pain to write a patch because by the time you have
someone superreviewing it, the patch is obsolete. Anyway, I'll give this a look
over for the review so that you don't have to wait for someone. We don't rubber
stamp, though, even for a tiny patch. Thanks for the patch and I'll look it
over. I just have to update the build tree first so give it a couple days.

Comment 223

[Skewer]

Attachment: Zipped icons with shadow

Due to the precedent set by Windows Media Player, Internet Explorer, Windows
Picture and Fax Viewer, Themes, and even Registry Viewer, and observed by
popular programs like WinZip and LiveJournal, I strongly suggest that the patch
to this bug ONLY receive approval on the condition that icons with the proper
drop shadow are used (at least in WinXP). These filenames are still using the
naming convention I used earlier, feel free to change one to accomodate the
other, but I suggest my style because it doesn't introduce
localization/confusion issues because it uses MIME types.

Comment 224

[Jez]

> All the drop shadows look just
> fine to me, they don't appear to be inconsistent or anything like that.

I think they look ****.

> If I
> ever end up patching this bug I will be using the drop shadow icons.

Well, you didn't patch it.  I did.  And I say use the icons without drop shadows.

> Due to the precedent set by Windows Media Player, Internet Explorer,

So we're suddenly copying everything that a few major players do now, are we? 
Mozilla isn't about just copying things; it's about being better, if possible. 
Icons don't have a 'standard' design, so don't give me this BS about a second
drop shadow being the 'standard', it's nothing of the sort.  Plenty of icons on
my machine have NO drop shadow (Office 2000 icons, Paint Shop Pro icons), and as
for the ones you listed.  Media Player has no second *alpha* drop shadow, for
the overlay, and Internet Explorer has no second drop shadow at all, more like a
dark outline, so standard it is not.

It comes down to an issue of look and feel, and I far prefer the icons without
the second drop shadow, they're less cluttered.

Comment 225

[Brian 'netdragon' Bober]

I'm going to test and review the patch now... All I'm interested in is the code.
We'll let drivers decide about the shadows. I'd rather not be the bad guy
(either way, I would be)

Remember when this is checked in to put everyone's name who provided icons.

Comment 226

[Brian 'netdragon' Bober]

Attachment: icons.zip with a few modifications

Thanks for remembering template.ico, but I think the name is ambigious.
Therefore, I renamed it to template-file.ico. I also added template-window.ico,
which is a template for giovanni's icons and should be in the tree. I also
added a readme.txt file since there should be documentation for this directory.


Contents of readme.txt:

***** BEGIN LICENSE BLOCK *****
Version: MPL 1.1/GPL 2.0/LGPL 2.1

The contents of this file are subject to the Mozilla Public License Version 
1.1 (the "License"); you may not use this file except in compliance with 
the License. You may obtain a copy of the License at 
http://www.mozilla.org/MPL/

Software distributed under the License is distributed on an "AS IS" basis,
WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
for the specific language governing rights and limitations under the
License.

The Original Code is readme.txt by Brian Bober

Portions created by the Initial Developer are Copyright (C) 2003
the Initial Developer. All Rights Reserved.

Contributor(s):

Alternatively, the contents of this file may be used under the terms of
either the GNU General Public License Version 2 or later (the "GPL"), or
the GNU Lesser General Public License Version 2.1 or later (the "LGPL"),
in which case the provisions of the GPL or the LGPL are applicable instead
of those above. If you wish to allow use of your version of this file only
under the terms of either the GPL or the LGPL, and not to allow others to
use your version of this file under the terms of the MPL, indicate your
decision by deleting the provisions above and replace them with the notice
and other provisions required by the GPL or the LGPL. If you do not delete
the provisions above, a recipient may use your version of this file under
the terms of any one of the MPL, the GPL or the LGPL.

***** END LICENSE BLOCK *****



The icons in this directory are Win32 program icons, file association icons, 
and window icons (to appear in the upper left corner of various windows).



Requirements:
Each icon should contain the follwing devices images:
48x48, 32x32, and 16x16 - 16 color
48x48, 32x32, and 16x16 - True color
48x48, 32x32, and 16x16 - True color XP (Contains alpha shadows)

At this time, we don't think 256 color is a good idea since Windows does
a good job dithering and some systems will use 256 color icons even when
True Color exists.

See bug http://bugzilla.mozilla.org/show_bug.cgi?id=99380 for a lot of rambling
about
icons.



Window icons:
Should be named using the following convention: [NAME]-window.ico where [NAME]
represents the name of the window. Example:
history-window.ico

Blank template icon should be available as: template-window.ico

XXXFIXME 
Some icons have been given names such as downloadManager.ico and is because 
there are two naming schemes for windows. This should be remedied. 
Bug http://bugzilla.mozilla.org/show_bug.cgi?id=199576
XXXFIXME


File association icons:
Should be named using the following convention: [NAME]-file.ico where [NAME]
represents the type of file it is. Example:
image-file.ico

Blank template icon should be available as: template-file.ico


Program icon:
Currently, the only available program icon is mozilla.ico

Comment 227

[Brian 'netdragon' Bober]

Attachment: zip containing shadowed overlays as an alternative

I also added the two files, and changed the name of the template on the zip
containing shadowed overlays skewer likes. I also renamed the other files to
correspond with the code Jeremy provided.

drivers will have to choose between this containing shadows on the overlay for
XP and the previous.

Skewer, Jeremy: Mark previous two icon zipfiles obsolete, please.

Comment 228

[Brian 'netdragon' Bober]

Comment on attachment 129648 [details] [diff] [review]
Patch v0.2 - also removes ICO association

Patch applied successfully and compiled successfully. For the most part,
everything looks great.

Everything seemed fine except that if you already had .ico associated, it stays
that way. 

You should make it remove the .ico association if it exists. Besides that, I
just have a few complaints about code listed below. Fix numbers 1-5, and you
have an r=

Bug 216187 is about fixing the icon association and re-enabling icon handling.


These are areas of the code that need to be fixed:

1. 

There were issues in your diff of tabs being used in source files (.c, .cpp,
.h). Please 

don't use tabs in source files. Use spaces instead. set your code editor to
replace tabs 

with spaces and double-check the file before submitting it next time. You can
make a script that will search for tabs in the diff file, even.

Problem areas:

mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp

+			 // Temp. disabling of ICO file handling -
+			 // see
http://bugzilla.mozilla.org/show_bug.cgi?id=214798

mozilla/xpfe/components/winhooks/nsWindowsHooks.cpp

+	    // ICO disable again
+		  // ICO disable again

mozilla/xpfe/components/winhooks/nsWindowsHooks.h

+		// Temp. disabling of ICO file handling -
+		// see http://bugzilla.mozilla.org/show_bug.cgi?id=214798
+		/* PRBool mHandleICO; */

mozilla/xpfe/components/prefwindow/resources/content/pref-winhooks.js

+			// Temp. disabling of ICO file handling -
+			// see
http://bugzilla.mozilla.org/show_bug.cgi?id=214798
+			//  "isHandlingICO",

mozilla/xpfe/components/prefwindow/resources/content/pref-winhooks.xul

+	  <!-- Temp. disabling of ICO file handling -

+		   listitem type="checkbox" id="isHandlingICO" 
label="&ico.label;" 

accesskey="&ico.accesskey;"/ -->


mozilla/xpfe/components/prefwindow/resources/content/win/platformPrefOverlay.xu
l


+			// Temp. disabling of ICO file handling -
+			// see
http://bugzilla.mozilla.org/show_bug.cgi?id=214798
+			//  testSettings.isHandlingICO	  = false;

2.

A little nitpick:

In places where you disable code like this:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooks
.cpp#91
I'd like it if the disabled code lined up with the non-disabled code. That
means moving the 
/* back to the beginning of the line or to the previous line depending on
whether the code 

is indented or not. I believe this will make the code look cleaner.


3. 

sr might complain about adding your name to the contributors field. We don't
really do that 

anymore, or the list would be way too long. If sr doesn't complain, then its
fine with me. People can track contributors through CVS blame. Since you are
going to 

resubmit a fixed version of this patch, I recommend obfuscating your email ie:
<foo AT 

NOSPAM bar.com> to prevent against getting spam. Its up to you, but spam is a
nasty thing.


4. 

Sorry I didn't think about this before, but we should change this:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooks
.cpp#90

const char *bmpExts[]  = { ".bmp", 0 };
to:
const char *bmpExts[]  = { ".bmp", ".rle", ".dib", 0 };

because .bmp files can also have the extension .rle and .dib


5.

Fix what I mentioned about .ico should have association removed if .ico is
already associated.


After that, you have r=

Comment 229

[Brian 'netdragon' Bober]

>Be nice if someone changed the status whiteboard to "Need r= and sr=; Requesting
>rs=;"... how do you become 'sufficiently empowered' to change it, anyway?

Contact Asa and ask him for the permissions. He will ask you to provide proof
you know what you are doing on Bugzilla.

Comment 230

[Jez]

Whew, let me say one thing: this code is a mess!!  I had to move a function
because of the original author's *lack of prototyping*!  Anyway, I think I've
now improved upon the patch and created a rather more elegant disabling of .ico
association.

> These are areas of the code that need to be fixed:
> 1. 
> There were issues in your diff of tabs being used in source files (.c, .cpp,
> .h). Please 
> don't use tabs in source files. Use spaces instead. set your code editor to
> replace tabs 

I didn't know spaces were needed; tabs seemed more sensible.  Done.

> 2.
> A little nitpick:
> In places where you disable code like this:
> http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/
> nsWindowsHooks.cpp#91
> I'd like it if the disabled code lined up with the non-disabled code. That
> means moving the 
> /* back to the beginning of the line or to the previous line depending on
> whether the code 
> is indented or not. I believe this will make the code look cleaner.

Done.

> 3. 
> sr might complain about adding your name to the contributors field. We don't
> really do that 
> anymore, or the list would be way too long. If sr doesn't complain, then its
> fine with me. People can track contributors through CVS blame. Since you are

Then why not remove the contributers line and add "Contributers: (see
www.mozilla.org)" or something?  Anyway, it's only one or two files :-)

> going to 
> resubmit a fixed version of this patch, I recommend obfuscating your email ie:
> <foo AT 
> NOSPAM bar.com> to prevent against getting spam. Its up to you, but spam is a
> nasty thing.

Are the spammers really persistent enough to download the Mozilla source to
harvest e-mail addresses?  :-)  I think I'll leave it as it is, especially as my
e-mail addy is already publically viewable on Bugzilla.

> 4. 
> Sorry I didn't think about this before, but we should change this:
> http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/
> nsWindowsHooks.cpp#90
> const char *bmpExts[]  = { ".bmp", 0 };
> to:
> const char *bmpExts[]  = { ".bmp", ".rle", ".dib", 0 };
> because .bmp files can also have the extension .rle and .dib

Done.

> 5.
> Fix what I mentioned about .ico should have association removed if .ico is
> already associated.

Done :-)  Had to read through a lot of messy code, but Mozilla should now test
to see if it's associated with .ico files, and disassociate itself if it is, on
Windows installations.  It's in a routine that's only run on Windows platforms
because, as far as I can gather, Mozilla doesn't try to associate itself with
filetypes on any other platforms; please tell me if I'm wrong about that.  I've
also removed the ICO filetype from the prefs box.

This version of the patch will be submitted as v0.3.

Comment 231

[Jez]

Attachment: Patch v0.3 - also removes ICO association

Built ok and runs fine on my computer.

Comment 232

[Jez]

Attachment: Patch v0.3 - also removes ICO association

Sorry - slight mod (removes a couple of tabs that sneaked in).

Comment 233

[Brian 'netdragon' Bober]

>Then why not remove the contributers line and add "Contributers: (see
>www.mozilla.org)" or something?  Anyway, it's only one or two files :-)
I was just mentioning sr might care, since I don't really care. I think we need
a better way of showing specific contributions than either CVS blame or through
source files. Currently, all we have that most people would see is a
contributors list on about:credits, but it doesn't show specifically what they
do. I think what exactly contributors do should be more visible than CVS Blame,
but of course having a 500 line list of contributors in some source files
wouldn't be very good, plus most people wouldn't see it.

>Are the spammers really persistent enough to download the Mozilla source to
>harvest e-mail addresses?  :-)  I think I'll leave it as it is, especially as
>my e-mail addy is already publically viewable on Bugzilla.

I meant more that their spambots can just peruse LXR. I guess there is no point
to doing this because we need obfuscating built into LXR, and not rely on people
doing it on their own in 8 million different ways.

There is a bug about obfuscating emails on LXR:
Bug 184456 - lxr.mozilla.org is a spammer's paradise


I'm about to review the patch now.

Comment 234

[Brian 'netdragon' Bober]

Comment on attachment 129873 [details] [diff] [review]
Patch v0.3 - also removes ICO association

r= Brian Bober (netdragon)

Bill: I'm not sure if you would want to review a patch on a different component
(personally, I believe this bug should be in XP Apps), but do you mind doing
the sr on this since Jag's backlogged with reviews?

Jeremy:
Everything works great, and applied and compiled perfectly. I was also
impressed that the icon was changed back immediately upon opening of Mozilla.
:-) I noticed a couple things in the code, but they were insignificant and
didn't warrant denying review in my opinion.

Upon checkin (after sr= and a=), this is who should be mentioned:
Jeremy Morton (Jez): misc-file.ico, image-file.ico, template-file.ico,
script-file.ico
Jeremy Morton (Jez): Code patch
SkewerMZ: gif-file.ico, xml-file.ico
Malcolm Scott: jpeg-file.ico
Brian Bober (netdragon): xul-file.ico template-window.ico readme.txt

Did I miss anyone or something anyone did? (Speak now or forever hold your
peace ;-)

I had one concern (about scoping) about something you added:
SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL);
It's a global Windows API function, so it would probably be useful to put it as
 ::SHChangeNotify so someone reading the source will know its a global scope.
The other time it was used in existing code, they did the same thing as you
did. I noticed that the file does scope some API functions, but doesn't scope
others, but this isn't your fault because it was already like this. 

It also doesn't scope putPRBoolIntoRegistry, which is another inconsistency,
but I imagine they didn't do that because it's a global function within the
same C++ file so there is no reason people wouldn't know about it (besides its
obviously not a Windows API function). This could cause problems if the
function were hidden by a function within the class, but its probably never
going to happen, and its the job of whoever changes the code to make sure they
don't break existing code.

+nsresult putPRBoolIntoRegistry( const char* valueName,
+				 nsIWindowsHooksSettings *prefs,
+				 nsWindowsHooksSettings::getter memFun )

You moved this function before CheckSettings, but could have just put the
function prototype at the top of the C++ file and saved a little messiness in
the diff.

None of these are big enough reasons to deny review in my opinion, just things
I noticed and perhaps sr will want these to be dealt with, but in my opinion
its overly picky and will just bloat the diff file further. I just didn't want
to get yelled at for not noticing them.

> It's in a routine that's only run on Windows platforms
> because, as far as I can gather, Mozilla doesn't try to associate itself with
> filetypes on any other platforms; please tell me if I'm wrong about that.

OS/2 might, but that's Mike Kaply's (IBM developer) arena and you don't have to
worry about it. Mac might, but I'm not sure because I don't use Macs (plus the
icons here wouldn't be liked by picky Mac users, anyway). Therefore, Windows is
all we need to worry about. If OS/2 needs to deal with this, it will have to be
a separate bug and patched by someone who develops on OS/2.

Comment 235

[Brian 'netdragon' Bober]

Jeremy: I changed the super review to Jag since you heard in #mozilla that Law
might not be working on the project anymore and would explain why his queue was
so small...

If you don't actively seek superreview though, it might be weeks until you have
someone look at it. I know this from experience.

http://www.mozilla.org/hacking/reviewers.html

Comment 236

[Brian 'netdragon' Bober]

Of interest:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/winxpicons.asp
Windows XP icon design guide (just found it)

Comment 237

[Jez]

Pardon me if I don't listen to Microsoft's every word on how to design icons. 
They're not particularly wonderful at it themselves, and as that page is for XP,
they refuse to acknowledge that 256 color icons suck and stop true color icons
displaying on some older versions of Windows.

Comment 238

[Brian 'netdragon' Bober]

I filed a bug on Cross Platform Icons Guidelines documentation - bug 216364

Jeremy: Can you please mention in that bug about the 256 color icons not being
displayed correctly on some systems? Please also provide the Windows version and
color depth it was being run at. Thanks.

Comment 239

[Skewer]

256 color icons aren't necessary for two reasons:

1. WinXP is very pushy about wanting 16-bit color or higher. Very few people
will have 256 colors in that OS.
2. Any situation where 256 colors are used the 16-color icons will suffice. If
someone is unhappy with seeing 16-color icons they need to get their color depth
up to date.

It's better to have high-quality in 16-bit than 8-bit at the expense of 16-bit.

Comment 240

[Jez]

Yep.  For once I'm in total agreement with Skewer on this one.

Comment 241

[[e-mail]]

If you want to reset the ICO icons exactly once, all you need to do is to check
for the existence of the following *value*
HKEY_LOCAL_MACHINE\Software\Classes\MozillaICO\DefaultIcon
of the key HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Desktop
and if it exists, remove it and reset the MozillaICO icon
...new versions of mozilla should never create that value, of course...

Comment 242

[Brian 'netdragon' Bober]

Neil: Cool stuff. Thanks. That's bug 216187 btw.

Comment 243

[Malcolm Scott]

Attachment: Janet's e-mail (.EML) icon

Seems we're still missing an icon for e-mail files (.EML, and possibly .SNM
(whatever that is)). Here's one made by my sister, Janet Scott. Hopefully it
won't be too difficult to adapt the patch to include this icon, if you like it.


Comments?

Comment 244

[Brian 'netdragon' Bober]

I'll modify the zip files (I will want to make some changes to the readme.txt),
and Jeremy can make a quick change to nsWinHooks.cpp

I'd like to hear what people say about it before I make the zips, so that I
don't waste time. There is nothing stopping Jeremy from adding it to the code
immediately, though.

Skewer: We'll need a shadowed overlay if everyone likes it.

Comment 245

[Skewer]

Does the code support a .EML icon?

Comment 246

[Brian 'netdragon' Bober]

> Does the code support a .EML icon?

Yes. With minor changes (1-3 lines) to each of the files included in the patch

Comment 247

[Skewer]

Before I add any more drop shadows... can we get any kind of official
word/decision whether we're using them or not?

Comment 248

[Brian 'netdragon' Bober]

I believe we will. The icons with the shadow overlays look better. The problem
is that the <X> and the gif image are not shown with an overlay that is
shadowed. Looking at that, it appears inconsistant. You can't overlay them,
though, because it would look like garbage. Do people think this inconsistancy
is a big deal?

Comment 249

[Jez]

Ugh.

Yes, the inconsistency does bother me, it sucks.  As does the second drop
shadow.  Don't use it, ffs!

Comment 250

[Brian 'netdragon' Bober]

Personally, if the inconsistancy is fixed... I'm all for the drop shadows on
overlays. I think it looks spiffy. Skewer: Since you made the GIF and XML icons,
can you please modify them a bit so they will look good with drop shadows?
Perhaps you could for the GIF do circles and triangles overlapping so its all
connected. For the XML, I have no clue but I'll leave that to your creative
genius. After that, I believe the drop shadows would be good to use. Not only do
they look spiffy, mind you, but they also give more contrast for the overlay.
With the inconsistancy out of the way, I'll be willing to do battle with those
against the drop shadows ;-)

Replacing URL to compendium.
Jez: Please provide a link to
http://timeless.haque.net/mozilla/icons/wishlist.html on your page so timeless
doesn't get angry.

Jeremy: When you update the patch (which doesn't depend on the .eml icon's drop
shadow or not), I'll carry the review+ over, but since I'm not module owner,
you'll still need the sr= and a= (if they are requiring a=, atm). That means you
should send an email to [e-mail] asking for an sr= with reasons why
this bug should be reviewed before others. Jag isn't the only one that can
review XPApps, and with his backlog of reviews, it doesn't look like he'll be
getting to it any time soon unless he gives it precedence. By the way, even
though this is in themes, it really should be reviewed by XPApps reviewers.

Comment 251

[Skewer]

  Personally, if the inconsistancy is fixed... I'm all for the drop shadows on
  overlays. I think it looks spiffy. Skewer: Since you made the GIF and XML
  icons, can you please modify them a bit so they will look good with drop
  shadows? Perhaps you could for the GIF do circles and triangles overlapping
  so its all connected. For the XML, I have no clue but I'll leave that to your
  creative genius. After that, I believe the drop shadows would be good to use.
  Not only do they look spiffy, mind you, but they also give more contrast for
  the overlay. With the inconsistancy out of the way, I'll be willing to do
  battle with those against the drop shadows ;-)

If I can be guaranteed that the non-shadowed icons will NOT be checked into
Mozilla, I'll do it. This isn't the kind of decision the maintainers have time
or even much interest to decide, so we, in the know, need to make it. And from
an objective standpoint, there's no reason not to have drop shadows when
personal opinion is set aside for the standard behavior in a WinXP environment.

Comment 252

[Brian 'netdragon' Bober]

The answer is: "Yes, if you fix the two icons and if super reviewers or drivers
don't overturn the decision I made as reviewer."

Comment 253

[Jez]

Brian: I hate to say it, but your attitude sucks.  As the reviewer, you're there
to review *code*.  Icon design is entirely subjective, and it would seem most
appropriate to me for you to respect the wishes of the *main icon designer* on
the drop shadows issue.  It's not the kind of thing a reviewer should be
overruling.  As for Skewer's 'default icon behaviour', I'll just mention again
for the millionth time that there is NO default icon behaviour in Windows, some
overlays have drop shadows, some DON'T.

Comment 254

[Brian 'netdragon' Bober]

Actually, my attitude has been the only balanced one on this bug. It seems you
are upset because you don't like the drop shadows and are making a personal
attack on me claiming I have an issue with my attitude which is actually a bit
hypocritical because you have been attacking the drop shadows on the overlays
that Skewer worked hard on adding in.

I don't consider you the main icon designer, but a volunteer who has been active
in this bugfix, submitted the patch, and provided 3 of the 6 icons available
which I thank you for. That doesn't make you the owner of the module, nor the
one who makes the final decision on whether or not drop shadows make it into the
tree.

As far as I'm concerned, both you and Skewer have equal say in whether or not
drop shadows appear since you are both knowledgable people, and that poses a
significant problem because no one else is giving their opinion on the matter.
drivers are the one to make the final decision, but as yet they have not
rendered their decision. Therefore, as the 3rd person to have an opinion on the
matter, and the one reviewing the patch, I am the tiebreaker. I want to see
Skewer's versions of the icons (they still will be credited to the original
authors) at least available for drivers to mull over, and hopefully chosen to
appear in the tree.

This issue is bogging down the implementation of this bug. Since I grow tired of
this, I will talk to Jason Kersey to ask him to make a decision on it. His
decision will be final because we need to move on.

Comment 255

[Brian 'netdragon' Bober]

And you are right, it is subjective. That means its something we are better off
someone making a firm decision on so that we can move on. kerz has the authority
to make this decision, so hopefully he'll do it.

Comment 256

[Skewer]

Just to clarify, what I'm asking is that we don't even *submit* the icons with
incorrect drop shadow. It's a waste of their time to have to deal with that, and
a waste of my time to put effort into fixing icons if they're not guaranteed to
be picked. So Brian, I would need you to review on the condition that an archive
which I will attach (with whatever naming scheme you specify) containing *only*
the drop shadow icons, will be the one you are reviewing for inclusion in Mozilla.

JM: If you are unhappy with the reviewer's decision then find someone else to
review your submission. It is completely within the reviewer's authority to
decide which icons will be used.

Comment 257

[Jez]

Skewer: I asked about you.  People think you're an annoying person who
contributes very little to Mozilla and **** people off a lot.  Now I know why.

Brian: This request is beyond a joke.

Comment 258

[Jez]

Comment on attachment 129873 [details] [diff] [review]
Patch v0.3 - also removes ICO association

Removing sr request.  If Brian capitulates to Skewer's totally ludicrous
demands, it would be wholly inappropriate for this to go to suprrreview.

Comment 259

[[e-mail]]

Attachment: Possible "light red" background

The best I could do in 16 colours.

Comment 260

[Jez]

Attachment: Jez's proposed e-mail icon

Could I propose this as a slightly better e-mail icon than Janet's?  It fits in
more with the 'Chrome' look for Mozilla.

Neil: Mmm, I know it's all subjective, but I don't think that one looks as good
as the current 16 color template icon.	Bit too... bright and fuzzy.

Comment 261

[Malcolm Scott]

Jez: I like the idea, but at 48x48 (and slightly at 32x32) it looks like the
envelope has been scaled up badly. It looks a bit ragged around the borders.

Is there a higher res version of the envelope available anywhere? 

Also, don't forget that the icon will possibly/probably end up used for Firebird
as well, where it doesn't fit into the chrome at all.

Comment 262

[Brian 'netdragon' Bober]

From this point on, my review only applies to the code patch, as an initial code
review (meaning you still need sr=), and not the icons. You'll have to find
someone else to review the set of icons. Therefore, I'm not going to say
anything more about which should be used. Skewer: I'd suggest if you want to
give drop shadows a chance, you keep your collection up to date.

Comment 263

[Brian 'netdragon' Bober]

>Skewer: I asked about you.  People think you're an annoying person who
>contributes very little to Mozilla and pisses people off a lot.  Now I know why.

Jeremy: Also, I don't think its appropriate to say something like that to Skewer
on Bugzilla. In his defence, he might have a somewhat abrasive attitude at
times, but he does have a lot of contributions. Anyway, that's not something
that helps this bug any, so its best said through private email. No one manages
to go through the Mozilla project without pissing people off from time-to-time.
Its the nature of the beast. Let's try to keep things civil and productive.

Comment 264

[Jez]

> Jez: I like the idea, but at 48x48 (and slightly at 32x32) it looks like the
> envelope has been scaled up badly. It looks a bit ragged around the borders.

Well, I thought it looked OK, but it's *extremely* difficult to scale icons up
(the 48x48 is scaled up slightly), and it's even more difficult to make
antialiased borders look good :-)  I did the best I could... any other changes
seem to make it look worse, not better.  Anyone good at touching images up is
welcome to try and make them look better.

> Is there a higher res version of the envelope available anywhere? 

No, I nabbed the source off the Mozilla Mail toolbar icons so the 32x32 one is
actually the closest to the source size.

> Also, don't forget that the icon will possibly/probably end up used for
> Firebird as well, where it doesn't fit into the chrome at all.

Firebird's a browser.  If it were used for anything, it'd be Thunderbird, but
seeing as they're trying to get their own identities (as you said, not Chrome),
I see no reason why they'd want to use exactly the same icons?  They could
certainly modify the icons they didn't like.  However, this seems more
appropriate for Mozilla's Chrome look than the earlier submitted e-mail icon.

Comment 265

[Skewer]

Drop shadows don't need/won't benefit from my help. If sr knows what it's doing
it will ask for drop-shadow icons. If the wrong icons are checked in I will file
a new bug to fix the drop shadow.

Comment 266

[Skewer]

Also, I suggest that sr look at the general tone of the posts for the only
person who opposes the drop shadow:

  Removed that infernal second drop shadow.  I think it looks crap.

  I hate to say it, but your attitude sucks.

  Skewer: I asked about you.  People think you're an annoying person who
  contributes very little to Mozilla and pisses people off a lot.  Now I know
  why.

  Brian: This request is beyond a joke.

Does this kid know anything about icon design? Or for that matter, the baffling
physics that allows a page to cast a shadow, but not an overlay?

Comment 267

[Jez]

Skewer: That's no more annoying (in fact probably less so) than your self
righteousness...
"NO. N-O. Those icons are terrible.  If I could veto those icons I would,
they're a step backwards from even what we do now"
"like it or not, the drop shadow on the icon is the *correct* behavior.  If I
ever end up patching this bug I will be using the drop shadow icons."
"If I can be guaranteed that the non-shadowed icons will NOT be checked into
Mozilla, I'll do it. This isn't the kind of decision the maintainers have time
or even much interest to decide, so we*, in the know, need to make it." * - read
'I'.
"Just to clarify, what I'm asking is that we don't even *submit* the icons with
incorrect drop shadow."
"I would need you to review on the condition that an archive
which I will attach ... will be the one you are reviewing for inclusion in Mozilla."

With that out of the way,
> Or for that matter, the baffling
> physics that allows a page to cast a shadow, but not an overlay?

Sure.  It's simple 3d.  All it means is that instead of the overlay appearing to
hover above the red page, it looks like it's just sitting on (glued or
something) onto the page.  This looks better.  Two drop shadows is overkill.  If
you're gonna hover the overlay, you might as well not bother with the red page,
just use the overlay on its own.

Comment 268

[Malcolm Scott]

Jez: Netscape's Webmail service (http://home.netscape.com/webmail) uses the same
envelope image, in higher resolution, in various places around its website. E.g.:

-> Huge envelope from the Webmail sign in page:
   http://channel.netscape.com/sns2/images/b_mail.gif

-> Various toolbar buttons featuring the envelope; these are larger than
Mozilla's toolbar icons and might just be the right size for the 48px icon:
   http://ncmail.netscape.com/include/nc/images/tools_get.gif
   http://ncmail.netscape.com/include/nc/images/tools_keepasnew.gif
   http://ncmail.netscape.com/include/nc/images/tools_delete.gif

Is there any reason why we shouldn't use these? They are obviously based on the
same original artwork as the envelope used in Mozilla, so I don't see why not.


PS: I was obviously half-asleep when I mentioned Firebird; obviously Firebird
won't need an icon for e-mail messages. It's just that in bug 214054 it was
agreed that the icons produced in this bug could be used for Firebird as well
(with slight modifications).

Comment 269

[Jez]

Malcolm: Actually, those toolbar icons seem to be exactly the same size as
Mozilla Mail's.  However, that front page image is fantastic!  Slightly more
slant on the envelope, too.  I think I'll try to redesign the icon using that as
a base.

Comment 270

[Jez]

Attachment: Jez's slightly redesigned e-mail icon

This is my redesigned icon based on the image at
http://channel.netscape.com/sns2/images/b_mail.gif

Comment 271

[Hanspeter Niederstrasser]

The lower edge (and to a lesser extent the top edge) of the envelope in
attachment 130266 [details] (redesigned envelope by Jez) is somewhat jagged at 32x32 as if
the cutout from the master wasn't aliased correctly.  The 48x48 looks very good
though.  Also, there are 2 white pixels along the lower-left side (the part that
is outside the red sheet) and 1 on the left side of the envelope.  When viewed
against a dark background (like most desktops), those pixels stand out.  This is
at 32x32, didn't check at 48x48.  Without being able to edit the icon, I can
imagine that it might be an issue of alpha transparency (? I'm on WinXP).

Comment 272

[Jez]

Attachment: Jez's slightly redesigned redesigned e-mail icon

Well, I think this is getting a little pedantic, but I've removed the lightish
pixels on the 32x32 and 16x16 icons... I'm not gonna change the 48x48 one as
they help to smooth out the borders.

> The lower edge (and to a lesser extent the top edge) of the envelope in
> attachment 130266 [details] (redesigned envelope by Jez) is somewhat jagged at 32x32

No idea why you say that.  It looks pretty smooth to me, you'd need to be a
hawk to call that 'jagged' :-)

> When viewed
> against a dark background (like most desktops), those pixels stand out.

Most desktops?	I always have light backgrounds (I quite like the default WinXP
'Bliss' background), dark ones depress the hell out of me.  I would've thought
most people had a lightish background for that reason and because light pixels
tend to look very ugly on them, but the reverse is not true.

Comment 273

[Skewer]

Just so I may make my opinion briefly be known:

I think an overlay is the wrong approach for a .EML icon, if such an icon truly
is needed. If we're trying to work an envelope into the icon, let's have it look
like the envelope is part of the icon, not an overlay. An @ sign might be an
appropriate overlay but that would look cheap.

Comment 274

[Jez]

As I was making the icon, that thought passed through my head.  But then I
thought "this is a document, it's associated with a Mozilla suite program and
it's comprised of text, no less."  So it's appropriate.  Don't fall into the 'IE
does this, so we have to' trap.

Comment 275

[Jez]

Comment on attachment 129873 [details] [diff] [review]
Patch v0.3 - also removes ICO association

> (From update of attachment 129873 [details] [diff] [review])
> r= Brian Bober (netdragon)

Requesting additional r=, from module owner or designated peer.

Comment 276

[Brian 'netdragon' Bober]

Jez: you are going to have to actively seek review on this. module ownership is
a mess, atm. If you can manage to get Blake or Jag to review it, you might not
need both r= and sr= (only one or the other) since this is not a major patch and
one reviewer more knowledgable than I about XPFE should be able to handle it.
Anyway, I didn't see an update to the patch. That means this icon won't be
installed into the distro. Just edit the makefile and packages-win file for now
and don't worry about adding the association to any other parts of the patch
unless you want to - we can do that seperately. Nor is there an update for the
.zip file. Do that first before seeking review.

As for Firebird, we are probably be tossing Seamonkey out the window within the
year, and therefore Firebird -> Mozilla in the future. For now, we'd probably
use a different set for Firebird as not to confuse people, but in the future if
Firebird becomes Mozilla Browser, then I don't see why the icons wouldn't apply.
 The icons should be independent of selected theme, and personally I believe the
 blue envelope looks too much like modern. I'd rather see a grey - white
gradient. Envelopes are white, not blue. The icons are not theme dependent at
the moment, and until then -> XPAPPS so there is no confusion. Of course, I'm
leaving Kerz as bug owner.

This overlay thing is why I'm glad I'm not a graphic artist. Let's let it rest
and the sr can make the decision. You don't have to agree with his or her
decision, but the idea is its a mediation type thing. He'll read all the
comments and decide based on that.

::currently typing with one hand and the other covered in cookie dough being
devoured, surrounded by a pile of college books, wires, boxes and other stuff
throughout apartment that hasn't been unpacked yet while thinking about homework
already due tomorrow::

Comment 277

[Jez]

> If you can manage to get Blake or Jag to review it

To that end, does anyone know 'Blake's current e-mail address?  The address that
I tried from the module owners page seems to be broken now, I got this error back:
  [e-mail]
    host lookup did not complete: retry timeout exceeded

> Anyway, I didn't see an update to the patch. That means this icon won't be
> installed into the distro.

I presume you're talking about the e-mail icon.  That's because we haven't
settled on one yet.  I could easily add it to the patch when one is decided
upon, but the reviewer might even decide that it's not worth adding.

> personally I believe the blue envelope looks too much like modern.

I take your point.  Some envelopes are blue, actually, some are pink, etc...
they don't *have* to be white :-)  Being blue might just distinguish it as being
an 'e-mail' envelope and not a 'regular' envelope.  But i don't know.  Some
design a better icon, then.  I personally disliked the blue/violet one from Janet.

> until then -> XPAPPS so there is no confusion. Of course, I'm
> leaving Kerz as bug owner.

May I ask why?  He seems to have done virtually zero to move this bug along, and
maybe is too busy to deal with it, whereas everyone seems to be saying that Jag
is more appropriate to be associated with this bug.

Comment 278

[timeless]

it doesn't matter who owns it.

Comment 279

[Brian 'netdragon' Bober]

I don't have time to check on this: Do we hook up .eml just like we would for
any other extension, or do we have to do something special because its handled
by Mailnews? I can check on this in maybe a week.

>I presume you're talking about the e-mail icon.  That's because we haven't
>settled on one yet.

As I said before, that is irrelevant. You don't need to settle on an icon to
write it into code. You only need to know the name of the icon, which should be
file-eml.ico or whatever.

>I could easily add it to the patch when one is decided
>upon, but the reviewer might even decide that it's not worth adding.

It is worth adding because its a file type specific to Mozilla Mail which is
part of Seamonkey so it can be installed into the distro location just like the
other icons. The icons can always be changed within the .zip file independant of
the patch. We definately need an .eml icon. This is not something you need a
superreviewer to decide for you. The only thing that I want someone else to
decide is about the drop shadows because we need someone unbiased (like timeless
;-) ) to look at all the comments and make a fair decision.

>Some design a better icon, then.  I personally disliked the blue/violet one
>from Janet.

Its good enough for now. If people complain that the icon looks too much like
its only for the modern theme, we can change it. I want this to make it in by
1.5 or at least be available for drivers by 1.5. If you can figure out how to
hook up .eml, then feel free to do it, otherwise just make it so that the icon
is installed into the icon directory by editing Makefile and packages-win

>May I ask why?  He seems to have done virtually zero to move this bug along,
>and maybe is too busy to deal with it, whereas everyone seems to be saying that
>Jag is more appropriate to be associated with this bug.

timeless is right, and you shouldn't just change bug owner without asking. Kerz
must want to see the icons or something. Just because he hasn't commented
doesn't mean he's not keeping an eye on it. If he doesn't want this bug, he will
ask someone to take it. He knows what he's doing and there must be a reason he
wants to own this bug.

Comment 280

[Jez]

Attachment: Patch v0.3 - also removes .ICO association (Jez)

Specifying individual reviewers now.

Comment 281

[Jez]

Attachment: Icons that are required by Patch v0.3 (Jez)

Must unzip these icons into the sourcetree for Patch v0.3 to work.

Comment 282

[Robert Accettura [:raccettura]]

I'm loving the icons on each (much better than earlier).

But shouldn't all the icons have something that makes them specifically Mozilla
(the light red may not be adequate).  Perhaps a tiny lizard, or "Moz" somewhere.

Just something to make it clear that it's a file that's associated with Mozilla.

I don't think the light red does the job.

But I love the icons overall.  Just need something to brand them.  Perhaps
watermark Moz?

Comment 283

[Malcolm Scott]

Robert: this was discussed at some length earlier, and it was agreed that the
red page was sufficient to show an association with Mozilla, since nothing else
(as far as we know) uses a red page icon.

There was a "watermark" icon floating around earlier (originally my idea, and
implemented by Jeremy) but we agreed that it would look too cluttered to have
both the lizard head watermark and an overlay indicating the file type.

Comment 284

[Brian 'netdragon' Bober]

Why isn't there a request for review? Even if you are actively seeking review,
you should put review? for the zip and patch.

Comment 285

[Jez]

Comment on attachment 130838 [details] [diff] [review]
Patch v0.3 - also removes .ICO association (Jez)

Is now.

Comment 286

[Bill Mason]

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

Comment 287

[Brian 'netdragon' Bober]

This bug is still waiting for review.

Comment 288

[Brian 'netdragon' Bober]

Jeremy: Some bad news (well, not that bad -- just means you'll have to update
the patch :-(  ).

http://lxr.mozilla.org/seamonkey/source/xpfe/components/winhooks/nsWindowsHooks.cpp#85
This needs .jpe added to the list as Skewer mentioned in
http://bugzilla.mozilla.org/show_bug.cgi?id=99380#c12

While you are at it, you might want to think of any other weird versions of the
extensions that we didn't think about.

Also mentioned in http://bugzilla.mozilla.org/show_bug.cgi?id=216501#c28

Comment 289

[Jez]

No matter Brian, I'm washing my hands of this bug.

1) I can't get Mozilla to compile anymore.  It's screwed on Windows systems. 
You have to jump thru hoops to get it to compile.  This sucks.
2) Idiots like Skewer want to screw around with my icon design.  I don't care
anymore.
3) Nobody can be bothered to review it.

Bye bye.

Comment 290

[[e-mail]]

Comment on attachment 130838 [details] [diff] [review]
Patch v0.3 - also removes .ICO association (Jez)

>+bin\chrome\icons\default\gif-file.ico
>+bin\chrome\icons\default\misc-file.ico
>+bin\chrome\icons\default\image-file.ico
>+bin\chrome\icons\default\jpeg-file.ico
>+bin\chrome\icons\default\script-file.ico
>+bin\chrome\icons\default\xml-file.ico
>+bin\chrome\icons\default\xul-file.ico
Sorry, can't do this until staff decide on the right icons...

>+ifneq (,$(filter windows,$(MOZ_WIDGET_TOOLKIT)))
>+# Windows icons
>+DESKTOP_ICONS = \
I understand it's possible to use += to append only the extra icons. This way
if someone adds a new top-level icon it will won't need changing in two places.

>+        // Temp. disabling of ICO file handling -
>+        // see http://bugzilla.mozilla.org/show_bug.cgi?id=214798
This is no longer necessary.

Comment 291

[Jez]

> Sorry, can't do this until staff decide on the right icons...

The point of this bug is to add some appropriate icons for associated filetypes,
and not just the functional ability to do so (the original comment says "I
believe that there should be a difference between the icon displayed for html
documents and graphics, maybe even different icons for types of images.").  If
this is the attitude, then I suggest, with a heavy heart, that you change this
bug to WONTFIX.

That said, I'm not quite sure why the Mozilla people seem to be so worried about
branding 'going wrong' unless approved by some high-up committee... I think a
mountain is being made of a molehill here.

Comment 292

[Brian 'netdragon' Bober]

> Sorry, can't do this until staff decide on the right icons...

Neil: They can always be changed later with a simple binary commit to cvs, and
with months of asking for any input from staff members, we had to decide on our
own. The code is what needs the reviews, not the icons, since they can be
changed at a future date. We did talk to various staff members about the naming
of the icons, etc, just few actually looked over the appearance of the icons.

Jeremy: You said you are washing your hands of this bug. Do you want someone
else to fix the things Neil mentioned?

Comment 293

[Jez]

Attachment: Patch v0.4 - doesn't remove .ICO association

> Jeremy: You said you are washing your hands of this bug. Do you want someone
> else to fix the things Neil mentioned?

Nah, they're done in patch 0.4.  However I agree with you, the icons need to go
in the CVS along with the patch to make it at all useful, otherwise you have
exactly the same effect as the status quo.

Comment 294

[Jez]

Attachment: Icons that are required to make a patch for this bug meaningful

Comment 295

[chris hofmann]

lets finish this work in 1.7.  1.6-

Comment 296

[Jez]

Attachment: Patch v0.5 - doesn't remove .ICO association

Patch with correct Makefile.in.

Comment 297

[Bamm Gabriana]

I don't think there should be much discussion of how the icons should look. If 
mozilla (or just the installer) is just updated so that files 

    \chrome\icons\default\EXT-file.ico

would be mapped to files of the EXT extension, then all of us can create our 
own iconpacks with the icons of our choice and drop them all into this 
directory with our own XPI installers.

The community could then decide which iconpack should eventually be shipped 
with mozilla as the default.

Competition is good. Let us limit this bug to discussions on the codebase to 
implement it, which is really just a simple registry update. The best iconpack 
to include by default can be discussed in the newsgroups.

Comment 298

[[e-mail]]

Comment on attachment 137336 [details] [diff] [review]
Patch v0.5 - doesn't remove .ICO association

>+	script-file \
What's this file for? You don't seem to use it.

>-    mozillaMarkup( htmExts, "MozillaHTML", "HTML Document", "htmlfile",  "doc-file.ico");
>+    mozillaMarkup( htmExts, "MozillaHTML", "HTML Document", "htmlfile",  "misc-file.ico");
misc-file doesn't sound right for an html document...

Comment 299

[Jez]

(In reply to comment #298)
> (From update of attachment 137336 [details] [diff] [review])
> >+	script-file \
> What's this file for? You don't seem to use it.
It's in case Mozilla/FB/whatever has the option to, in the future, associate
itself with script files such as .js.  Futureproofing.

> 
> >-    mozillaMarkup( htmExts, "MozillaHTML", "HTML Document", "htmlfile", 
"doc-file.ico");
> >+    mozillaMarkup( htmExts, "MozillaHTML", "HTML Document", "htmlfile", 
"misc-file.ico");
> misc-file doesn't sound right for an html document...
This is by design, and I believe I explained it before.  Because HTML and
HTML-related documents "MozillaHTML" are the most common filetypes handled by
Mozilla, thereby giving them the common icon (just the Mozilla head, pretty
generic), I propose that the same icon be used for "MozillaHTML" type files as
all miscellaneous files.  Calling the icon 'misc-file.iso' is not saying
"MozillaHTML" files are miscellanious, but that "MozillaHTML" files should share
the same icon as miscellaneous files, because they're given the 'default'
Mozilla icon (by virtue of being the most common filetype handles by Mozilla).

Comment 300

[[e-mail]]

(In reply to comment #299)
>(In reply to comment #298)
>>(From update of attachment 137336 [details] [diff] [review])
>>>+	script-file \
>>What's this file for? You don't seem to use it.
>It's in case Mozilla/FB/whatever has the option to, in the future,
>associate itself with script files such as .js.  Futureproofing.
Well in that case I would like to see separate misc-file and html-file icons -
do that and you'll get r=me, at least on the parts where it counts...

Comment 301

[Jez]

Attachment: Icons that are required to make Patch v0.6 meaningful

Comment 302

[Jez]

Attachment: Patch v0.6

> Well in that case I would like to see separate misc-file and html-file icons

Alright.  Although I do think the HTML and misc file icons should be the same.

> do that and you'll get r=me, at least on the parts where it counts...

Ah, the icons?	:-)

Comment 303

[Jason Kersey]

mozilla.org has a branding committee, who is now in charge of artwork that goes
into the tree.  Please consult them before checking this in.  I think bart would
know who best to contact for this specific bug ([e-mail]).

Comment 304

[[e-mail]]

Comment on attachment 140604 [details] [diff] [review]
Patch v0.6

>+    xhtml( xhtmExts, "MozillaXHTML", "XHTML Document",       "",         "misc-file.ico"),
Almost right but I think this should be html-file.ico

Comment 305

[Jez]

> Almost right but I think this should be html-file.ico

No, the whole point is that XHTML is *NOT* HTML.  It's a misc filetype, so I
think that's a more appropriate icon.  Besides,
- The misc-file icon is the same as the HTML one anyway.
- We need *something* to use that icon :-)

Thanks for the r+, anyway.

Comment 306

[Jason Kersey]

Have you emailed bart and gotten a response?   If you charge through and get
reviews from people who aren't even paying attention, and check in unreviewed
icons, we're going to have a problem.

Comment 307

[jag (Peter Annema)]

It sounds like you need to get an r= on the artwork from bart. Can you request
r= from him on the artwork?

Comment 308

[jag (Peter Annema)]

Comment on attachment 140604 [details] [diff] [review]
Patch v0.6

sr=jag.

This looks good to me, but don't check this in until the artwork has been
approved.

Comment 309

[Jez]

kerz: it seems Bartholemew goes by the e-mail '[e-mail]' on Bugzilla. 
I've put an r? on the icons.

Comment 310

[bart decrem, not checking bugmail]

I think I'm all done.  I just gave this a review+. 

Also see Steven Garrity's comments below - he heads the visual identity team.  

Cheers,

Bart



-------- Original Message --------
Subject: 	Re: need advice - [Fwd: Re: Branding approval (bug #99380)]
Date: 	Sat, 07 Feb 2004 12:34:16 -0400
From: 	Steven Garrity <[e-mail]>
To: 	Bart Decrem <[e-mail]>, [e-mail]
References: 	<[e-mail]>


Bart,
Our team is planning on doing icons for any other necessary 
documents/files - which would include XUL files, images, etc. So, I 
would suggest waiting until these icons are done. That said, his patch 
would probably still be applicable, just with our ICO files in place of his.

I'm not sure how long it will take us to get those icons done - could be 
at least a few weeks.

Steven Garrity

Comment 311

[Christian :Biesinger (don't email me, ping me on IRC)]

checked in

Comment 312

[Robert Accettura [:raccettura]]

Attachment 140604 [details] [diff] makes this look like a windows only enhancement (at least from
the ifdef's I get that impression), but the release notes state:

> A new set of icons for files that are associated with Mozilla.

should be:
> On windows new set of icons for files that are associated with Mozilla.

Comment 313

[Brian 'netdragon' Bober]

Verified Fixed

Yes, this started out as a cross-platform bug, but eventually became
Windows-specific. Reason being there are different expectations on other
platforms (especially Mac) and one set shared by all platforms isn't possible.

Comment 314

[Jez]

Belated CCing so this shows up in my dead bugs search...