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.

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

Reporter, what OS are you using?

I am using Win 98 SE

themes?

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

->XPApps

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

->law

->marlon

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?

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

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.

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.)

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

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.

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

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

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

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.

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.

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.

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

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

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

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

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

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

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

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

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...

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.

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

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

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.

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.

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.

> 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.

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!

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

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.

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.

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.

> 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...

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.

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?

> 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! :-)

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).

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.

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?

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

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

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.

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' :-)

> 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 :-)

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.

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.

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

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.

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

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.

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.

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

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.)

> .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.

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.

Just fixing up a couple links: not bug #67, but comment #67 bug 199576 <- I forgot to write bug

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.

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.

> 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.

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.

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.

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?

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.

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.

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.

> 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!

> 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.

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.

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.

> 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.

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.

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.

> 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?

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.

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.

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).

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.

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'.

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

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

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.

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.

> 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...

> (and if possible a transparent layer > of just the paintbrush) Done. zip contains the paintbrush images with a white BG.

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.

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).

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.

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!)

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.

> "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.

> 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.

> 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?

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.

> 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.

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.

> 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.

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

> 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.

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.

> 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.

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.)

> 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. :-)

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.

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

> 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.

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).

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

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.

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?

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 :-/

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.

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

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.

> 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.

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.

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

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.

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.

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?

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?

> 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.

> > 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...)

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.

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.)

> 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.

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.

> 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.

> 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...

> 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.

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

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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

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.)

> 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.

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.

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

> 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.

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

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.

> 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.

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.

On second thought... Hand edited. This may be simpler than I thought.

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.

>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.

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.

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.

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.

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.

Test post -- receiving "no data" errors?

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!

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.

[removed to see if that stops the error] AddType image/x-icon ico Apache doesn't know what an ico file is yet.

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.

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.

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?

>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.

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

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. :-)

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.

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...

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.

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?

> 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.

.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.

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.

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.

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

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.

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.

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.

> 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.

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.

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 :-)

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.