<a class="header-button" href="https://bugzilla.mozilla.org/home" title="Go to home page"> Bugzilla

Comment 20

•

22 years ago

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

Comment 21

•

Matthias Versen [:Matti]

•

21 years ago

I've attached an .ico file containing icons I designed for use with *document* filetypes associated with Mozilla. I'm aware that it can deal with stuff other than images, but I happen to use another program to deal with them. As for the person who said that there's nothing worse than not being able to tell a GIF from a JPEG, I can tell them apart and have the same icon for nearly every image file. How? I have my shell set to show me file extensions. Seperate icons for different image types would bug me. Anyhow, the icon I submitted would be intended to be associated only with document filetypes dealt with by Mozilla, and hence it's a kind of piece of paper with the dinosaur head on it. I've associated it with some relevant filetypes on my machine (eg. HTM, HTML, XML) and frankly think it looks pretty cool :-) The .ico contains icons that are 16x16, 32x32 and 48x48 pixels in size, and there are 16 color and True color versions of each. There's no point in including 256 color versions, because Windows doesn't differentiate between them and true color (dunno why). Sorry it's only a .ico, I don't have the tools to create anything more advanced. Could you possibly make this the default icon for document-based filetypes that Mozilla supports, when Mozilla is associated with them? I like them better than the mozilla.exe icon because it differentiates documents from Mozilla itself.

Comment 37

•

Comment 43

•

21 years ago

Attached image Again, but viewable using a browser (obsolete) — Details

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.

Assignee

Comment 44

•

21 years ago

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

José Jeria

•

21 years ago

Attached image Windows 'blank' Mozilla icon (obsolete) — Details

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

Assignee

Comment 49

•

21 years ago

Attached image Windows 'watermark' Mozilla icon (obsolete) — Details

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.

•

21 years ago

The watermark icon was created by putting the Mozilla head images over the blank paper images with opacity 30. > I really like that watermarked icon - even in 16x16. However, I'm not sure how > well this would work for the other categories of icon (images, scripts, etc.). > Would you add another overlay - e.g. a paintbrush for images - on top of the > watermarked page, maybe in the top-left corner? If so, would that look cluttered > or messy? Or would you replace the watermarked lizard with the paintbrush? I'm not sure how cluttered it would look - it was your idea! I was thinking that the watermark would stay there for all icons, and the 'document group' overlay would be added. It may look cluttered. However, if you're proposing changing the watermark for each group of document, the only thing identifying the document as being opened by Mozilla is the red-page icon! If that is going to be the 'Mozilla document' identifier, my origianl idea would seem the best; just have that piece of paper with no watermark, and overlay the icon for the document group? Keeps the icon simple enough to be translated to 16 color, and maintains a unique identity for Mozilla files. But I definately like both the watermark AND the red-page better than the blue/grey 'M' :-)

Comment 55

•

21 years ago

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

Assignee

Comment 56

•

21 years ago

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

Comment 57

•

21 years ago

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.

Alex Hosking

Comment 58

•

•

21 years ago

Attached image GIF icon (XP format only) (obsolete) — Details

Assignee

Comment 65

•

21 years ago

Skewer: a couple of things: Could you tell me how you added the Windows XP drop shadow in attachment #128602 [details] and attachment #128603 [details] ? I'd quite like to know what 'tool' you used. Second, we've got to get this fundamental debate sorted out before we start really designing the non-general icons; some people want one icon for every file type (me :-) and some want a different icon for every file type (you :-). If we had a different icon for every filetype there would be HUNDREDS of different icons on the computer. That would drive me mad! Now, I think a good compromise between these views is the one proposed by Malcolm Scott in comment #46 - have a select few different icons, for different *groups* of filetypes. I think the groups he lists there are just about right; image, script, link, and the only change i'd make is to combine XML and HTML, they're too similar to warrant different icons. So, how about, instead of making an icon for every different image type and document type and script type and everything (we'd get about 50 icons, literally), we have an icon for: - ANY image format. GIF, JPEG, PNG. Paintbrush overlay? - ANY script format. JS, XUL. Cogwheel overlay? - ANY link. URL. Arrow overlay, but not the same as the default windows 'link' arrow so as to avoid confusion with an 'official' OS link? - ANY document format, and 'default' for a group that doesn't yet have an icon. HTML/XML. I suggest attachment #128636 [details]. In addition, an icon for any significantly different group of documents, handled by Mozilla, that I didn't mention up there. Wouldn't that be reasonable? More reasonable than one icon for each and every different filetype, anyway. ;-) - HTML, XML and any other 'm

Comment 66

•

Comment 78

•

21 years ago

But if you insist on using separate icons for the three major image formats, how do you suggest differentiating between these icons in a meaningful way (without, of course, resorting to printing the extensions on the icon... or other no-nos such as simply changing the colour of a picture frame, as I believe Microsoft used to do to distinguish image formats)? I'm curious why using different colors is considered a no-no? I think that's a very effective way to differentiate. The method I suggested earlier however is default icon (already partly made) for GIF, tree for PNG, digicam for JP(E)?G. And on another matter, I agree that the red page is just about sufficient to distinguish an icon as mozilla-owned, but I believe the watermarked version looks more professional, and it also emphasises the association with Mozilla by including the ubiquitous lizard head. And some of us happen to prefer the watermarked version. Look at the IE HTML icon. Look at the Windows Media Player icon. Look at the WinZip icon. What do they have in common? A floating, left-aligned identifying logo. I challenge you (another challenge) to find any high-profile WinXP app that uses this watermark method instead of the floating image. We can be beautiful by fitting in. Just because the watermarked icon looks nice by itself doesn't mean it's going to be acceptable in the real world of associated file icons. If you are extremely angry at someone, please talk to them personally via email or some other means. Otherwise, we will have to rename Bugzilla to Flamezilla. Personally I'm not angry at anyone... but I am correcting a few misconceptions before anyone goes to the trouble of making worthless progress on this bug based on those misconceptions. As for attachment 128744 [details], that would look bad whether you put effort into it or not, because this is another case of "let's make up our own arbitrary behavior for filetype icons so we can squeeze some branding into the icon," not unlike the watermark thing. Which is really what this is about: Is there truly a need for us to put our branding on the filetype icons? If anyone who isn't on a shared system or anything like that is surprised by an association being tied to our program, then we are being too pushy with grabbing associations. Otherwise the person would be well aware (and only need the red-page cue) that the file will, by default, open in Mozilla. Having said that I don't see any reason why we shouldn't use the XML and GIF icons as I demonstrated. And although it wouldn't be 100% correct, I think if we had an HTML, XML, and image icon (first is done, next two can be finished in about 10 minutes by me) and got them checked in together with necessary, expandable code, it would be great progress (certainly enough to warrant marking this bug FIXED). After that we can discuss the merits of JPEG/PNG identification in a new bug. And please consider for a moment, that I will never associate image file types to Mozilla. I have no reason to personally want this. It's just the correct behavior; it allows me to look at a folder full of images (in less than the clunky thumbnails mode) and tell whether an image is the full-size JPG grabbed from my digital camera, the optimized 8-bit PNG for my site, or the BMP file for use as wallpaper (default icon). Don't forget that the icon isn't just for Mozilla's purposes; this is what you will look at when you need to pick out a file to upload in an FTP program, or the file to burn to a CD-R. It may ultimately be decided by someone in charge at Mozilla that there's no reason to have JPEG/PNG icons simply because that would cause a bloat issue or because smart people don't usually assign image filetypes to Mozilla, or some other valid reason, but it is indeed the correct behavior. Oh, and to put down the myth of the need for a pref to retain old icons: Anyone who actually cares about something that trivial will know how to manually tweak it anyway. Not worth the trouble of a pref.

Comment 79

•

Comment 85

•

21 years ago

Attached image Your watermark icon but without the dino watermark and the head moved — Details

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.

Assignee

Comment 86

•

21 years ago

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

Michael Newton

Comment 87

•

21 years ago

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.

•

21 years ago

Attached image Preliminary paintbrush 'image' icon (obsolete) — Details

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

Assignee

Comment 97

•

21 years ago

Attached file Paintbrush images (obsolete) — Details

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

Comment 98

•

21 years ago

Attached image GIF/Default image icon (complete) — Details

Attachment #128670 - Attachment is obsolete: true

Comment 99

•

21 years ago

Attached image XML icon (complete) — Details

Attachment #128669 - Attachment is obsolete: true

Comment 100

•

21 years ago

•

21 years ago

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

Assignee

Comment 107

•

21 years ago

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

Comment 108

•

21 years ago

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.

Assignee

Comment 109

•

21 years ago

> At a bare minimum we're going to need the HTML, XML, and image icons to tell > those three types apart. Why different icons for HTML and XML? XML stands for 'eXtensible Markup Language', and is just HTML 'on drugs'. They're too similar to warrant seperate icons. I say leave them both with the Mozilla head, and leave users to see the file's extension / not care that much about which of those 2 it is. > As for the paintbrush, I have mixed feelings about that icon; > at 16x16 it is distinct but not recognizable. Agreed. I'm working on a palette icon right now, and it's looking much more promising. Suggest that overlays for icons be roughly square in shape, so they can be scaled down more effectively. > in the > future we should design for 16x16 and work our way up. Very few people use > 48x48 icons so it doesn't mean much if an icon only looks really good at that > size. Because it's perfectly possible to find overlays for icons that look good at all 3 sizes, I think we should make them look good at all sizes. It's much easier to start with a big icon and scale down than to start small and scale up (try adding detail to an image!!) so starting with 16x16 isn't a good idea. Just find overlays that can be scaled down well.

Comment 110

•

21 years ago

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.

Updated

•

21 years ago

Attachment #128603 - Attachment is obsolete: true

•

21 years ago

Attached image Windows 'blank' Mozilla icon (template) — Details

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

Attachment #128633 - Attachment is obsolete: true

Attachment #128635 - Attachment is obsolete: true

Comment 113

•

21 years ago

> If you've forgotten what the purpose of this bug is, re-read its > description. Different shell icons to identify *EACH* associated file type. Depends on what your definition of file type is. The bug doesn't say "file extension", it says "type". Our handling of images is poor compared to Windows Picture and Fax Viewer or ACDSee and it doesn't warrant having all those extra icons in the distribution for each extension when hardly anyone is going to associate images with Mozilla. You explained why you want every extension to have its own icon, but that doesn't seem necessary to me. I guess as long as you only do .png, .jpg/.jpeg, and .gif, and don't go overboard, I won't complain because its not worth it and it follows the behavior Windows does. If we eventually made this extensible, then add-ons that handle other image formats could install additional association icons. The paintbrush icon is a good idea for GIFs because they are usually graphic art, but perhaps we should just keep it simple and show a depiction of a picture for jpegs, shapes for gif since its usually drawn, and I have no clue for png since it could be both. I'd also personally like it if nothing protruded from the depiction of a document page unless its a mini application icon. If you want the paintbrush, I'd have it stand more upright so its contained within the page, and have it drawing a little something with some perspective. You could use a pencil, too.. And that might be easier to depict in 16x16. For the XML, it would look better if the <X> were moved inside of the page, and not extending outside of it and its a bit unreadable at 16x16. Also, this would allow you to make the document depiction larger and allow you to fit more on it. For HTML, something like this: ______________ _______ ______ _______ | | _______ | | ________ ------ _____ | | ________ | | ________ ------ ________ _______________ That depicts text floating around images (use your imagination :-) ) would be more appropriate than the <X> Looking at the icons Microsoft uses, I am increasingly warming up to the idea of just a red border since they look cleaner without a little dino head. It also gives more room. > Very few people use 48x48 icons so it doesn't mean much if an icon only looks > really good at that size. It is, because this size is what Linux uses, and we could convert the 48x48 true-color device image to the format Linux uses to keep cross-platform consistancy. Also, as resolutions become higher, people might start using them more often. 16x16 also needs cleaning up for all the attachments, as someone mentioned before. Making it so that everything is contained within the red page will give you 76 more pixels to work with inside the document image an image with only 256 pixels. Of course, we would have to leave a couple pixel columns open so it wouldn't look like the page is square. I believe that for consistancy, if one icon has everything contained within the document page depiction, it should be that way for every icon. I also noticed that the standard device images you don't normally see (I assume 16 color) have grey and white for the page background. Can't we use a lighter red like we did in the true-color images? You just need to change the palette for that one color. I also think it would be a good idea to come up with a common naming scheme for the icons. Something like imgGIF.ico, imgPNG.ico, imgDefault.ico, docXML.ico, docHTML.ico. This allows the icon names to reflect that its an image of type GIF, image of type PNG, document of type XML, etc. It also means we have consistancy. > Why different icons for HTML and XML? They are signifiicantly different. In fact, XUL, XHTML, and RDF files are all XML files with different namespaces. If we are going to do different icons for images, we should do different icons for those, also. We also need a default document icon (perhaps just a page with text). >They're both derivitaves of the same standard (SGML). That's a bit misleading. XML isn't a presentation language. HTML is to SGML as XUL is to XML. XUL's icon would be something graphical, while RDF would look better just as lines of text. The <X> is appropriate for XML because its just a language with no real presentation. >Because it's perfectly possible to find overlays for icons that look good at >all 3 sizes Agreed. It just takes time, patience, and artistic ability. I filed a new bug for creating an art/graphics component within the Marketing product (bug 214688) so we can hopefully get some graphic artists to head that component and make decisions about Mozilla graphics.

Comment 114

•

21 years ago

Attached image Windows blank template. Same as above except with new 16 color images (obsolete) — Details

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.

Attachment #128977 - Attachment is obsolete: true

Assignee

Comment 115

•

21 years ago

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

Updated

•

21 years ago

Attachment #128979 - Attachment is obsolete: true

Updated

•

21 years ago

Attachment #128977 - Attachment is obsolete: false

•

21 years ago

Attached image Windows 'HTML/general/misc' Mozilla icon — Details

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

Attachment #128636 - Attachment is obsolete: true

Assignee

•

21 years ago

Attached image XUL icon (obsolete) — Details

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

Attachment #128984 - Attachment is obsolete: true

Attachment #128986 - Attachment is obsolete: true

Comment 126

•

21 years ago

Attached image XUL icon again (obsolete) — Details

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.

Updated

•

21 years ago

Attachment #128994 - Attachment is obsolete: true

•

21 years ago

Attached image Windows 'image' Mozilla icon (obsolete) — Details

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.

Attachment #128855 - Attachment is obsolete: true

Attachment #128890 - Attachment is obsolete: true

Assignee

Comment 131

•

21 years ago

Attached image Windows 'image' Mozilla icon — Details

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

Attachment #129013 - Attachment is obsolete: true

Comment 132

•

21 years ago

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

Comment 133

•

21 years ago

•

21 years ago

Attached image Retouched XUL icon with gradients (obsolete) — Details

Assignee

Comment 142

•

21 years ago

Attached image Windows 'XUL' Mozilla icon (fixed) — Details

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.

Assignee

Comment 143

•

21 years ago

> The XUL icon is hard because its hard to convey the meaning of a UI element. I > think showing an application window will best convey the meaning. Yep. I like the 'application window' icon. The one thing I would say about it is that it's possibly to 'Windows default theme' biased... but then again, I suppose you've got to be biased towards *something*. > Windows icon images are of course similiar to BMP images with a few > differences (transparencies, multiple device images). That means they aren't a > compressed format. All of you are probably aware of this. That means that when > they are compressed for the installation program or zip file, they will be > compressed. I did some tests, and found they compress around 80-90% Irrelevant. This is no excuse to go creating hundreds of different icons. The best interface is to keep things as simple as possible. We already have plenty of 'freedom', but it should be used wisely. > I believe .url should be a different icon to .html - they're very different > things. I believe it should be left to the shell to overlay an arrow onto the HTML icon, identifying .url as the shortcut that it is. > Looking at attachment 69906 [details], I think we only need > icons for http:, https:, ftp: and mailto:. (And possibly news: as well? Not > sure.) Eh? This is ridiculous, and is exactly the kind of icon overkill I was warning against. We do *not* need an icon for each and every type of protocol. You should kill that idea stone dead. > Attachment 129014 [details] is much better than the paintbrush but the larger truecolor > versions are a bit bland; maybe you could use gradient colors in each paint > splotch? Nah, I think it looks fine as it is. I actually prefer the larger icons, I think they look great. Not everything has to have a gradient fill :-) By the way, Skewer, I hope you don't mind that I slightly altered your XUL icon (by 2 rows of pixels ;-); I think you should mark yours obsolete as the 48x48, 16 color version had the application window in slightly the wrong place. Apart from that, seems like a good icon.

Comment 144

•

21 years ago

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

Assignee

Comment 145

•

21 years ago

> So are you suggesting we use the HTML icon even for mailto: links? That sounds a > bit misleading to me, considering it doesn't even open in a browser window... I'm suggesting we use the general Mozilla icon, ie. the Mozilla head, for these protocol links, with (preferably) an OS-created overlay arrow to indicate a link file. As the Mozilla head is more general than a specific HTML icon, I think this would be quite sufficient.

Comment 146

•

21 years ago

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

Comment 147

•

•

21 years ago

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.

Assignee

Comment 157

•

21 years ago

Attached file Jez's Mozilla Icon Compendium — Details

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

Comment 158

•

21 years ago

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

Assignee

Comment 159

Comment 165

•

21 years ago

> I like the work being done... but I don't think the proposed icons will look > very attractive in OS X, or any OS that does/will use hi-rez icons. Even if > they are rendered hi-rez... they will look pretty bland and odd. That's why I specifically mark my icons as Windows icons. I think they'd be pretty portable to Linux, though. > Some OS X MS Office Icons: > http://design.iconfactory.com/pages/macicon/office.html My God, they call those ICONS?? I don't want an icon that takes up half my screen! What's the point? True, different icons would indeed need to be designed if someone wanted to view them at 500x500 :-) Does anyone actually browse with those things? > Those look good on any OS, and at Hi Rez. Oh? Try displaying them as a 16x16 icon. They wouldn't look good in my file browser. > Secondly. I'm personally in favor of the file format being on the icon: XML, > HTML, GIF, JPG. Then you're in the minority. It's a terrible idea. If the OS is hiding the file format, it's the OS's fault, not ours. An icon isn't there to replace that task.

Comment 166

•

21 years ago

the overlay either generates no shadow, or generates a shadow on top of the page. The general effect is supposed to be that the overlay is floating above the page. I can agree with that but it would be difficult to add that effect to the icons at this point, since many of them were hand-made on a single layer. If anyone wants to try to add the shadows to these icons they can try. I actually prefer the drop shadow to eminate as if the page and overlay are at the same level. Just think it looks a bit nicer. 2 shadows seem like overkill. But either the XML icon, or all the others need to be amended to get the shadows normalized. I can definitely say that adding a shadow under the <x> would look horrible. That <x> should be left as flat and nondimensional as it is. Also the image icon would look better as-is because it's not even so much of an overlay as objects on the page. The others could use a drop shadow on the page, but if nobody wants to do the work it's not a major issue. Probably the only way to get a drop shadow on the middle of these icons is to do it by hand. I like the work being done... but I don't think the proposed icons will look very attractive in OS X, or any OS that does/will use hi-rez icons. Even if they are rendered hi-rez... they will look pretty bland and odd. Do people really use icons that are that big? Seems like at any resolution below Super-Duper-Ultra-XGA you wouldn't be able to fit a folder of 30 document files onto the screen with icons that large. But regardless, the icons that are being done right now are for Windows only (.ICO format). I suggest that anyone making icons for different OSes should make the icons appropriate for the shell. So my suggestion would be to cleanly squeeze the file name into the icon. Perhaps like PhotoShop does (in that bar). So that a user can tell quickly. THIS IS A GIF. THIS IS A JPEG. For the dozenth time, that behavior is incorrect. The filetype may vary from the extension. The extension may vary from the filetype. Text causes localization issues. And it's almost impossible to read text that's imprinted on an icon.

Comment 167

•

Comment 184

•

21 years ago

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?

•

21 years ago

Looking at the remaining filetypes not yet given an icon in the 'wishlist', here are my thoughts (you can skip the penny): .java .class .jar .zip These strike me as filetypes that Mozilla shouldn't be dealing with. Are .jar files executable Java files? If so, maybe Mozilla could open them. But not .java or .class files, they should be left to an editor, and .zip should be left to the shell or a far more competent 3rd party program. .dtd .rdf I have to confess not having heard of these file formats before so I looked them up. They both seem to be declarative types of file, holding organised data for other files to access. I was thinking that these might be able to be grouped in with the XML icon, but the XML icon would need a redesign, removing the 'X' and reflecting a more general 'data resource file' group. .xpt .xpi What is an eXternal Page Table?? As for X-platform installer, maybe that would warrant an icon, but maybe the Mozilla head would do... .snm .eml Email files and SNM (????? Netscape Mail) would seem to warrant an icon. I would have thought that maybe Netscape's mail client would already have an icon for them, though...

Comment 190

•

21 years ago

Attached image Preliminary jpeg icon — Details

Take a look at this... I haven't done the 16x16 yet or 4 bit images, but I need some advice on how to make the 32x32 icon easier to see. It seems the colors or something make it not contrast enough. As I said, Mozilla doesn't Open .dtd files or .rdf files from explorer (unless there is something I don't know of) so we shouldn't provide an icon for these files types. .xpi should probably have something indicative that its an installer program, just like the .msi files have.

Comment 191

•

•

21 years ago

Attached image jpeg icon - Malcom w/ a bit of netdragon :-) i guess i'm bored — Details

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

Comment 198

•

21 years ago

Updated http://retrosnub.co.uk/mozicons/ to include Skewer's and netdragon's versions of my icon. Comments: --> Skewer's drop shadow is inconsistent with the one in Jez's original red page icon. It seems darker, and the corners aren't rounded. --> I like netdragon's improvements, however it seems to destroy the 16 colour version. E.g. the water goes grey. Compare the different 16 colour icons on my page to see what I mean. (I pretty much redid the 16 colour versions from scratch. You appear to have simply let your software reduce the colour depth for you automatically.) BTW, credit where credit's due: I got the inspiration for the picture from a painting my Dad did many years ago, and which happens to be on the wall near my computer :) It's somewhere in the English Lake District, although I can't remember where.

Comment 199

•

21 years ago

there's a rule apple has about any files you ship/generate which your users can see, but ignoring that here are the files that matter wrt dtds: mathml.dtd xhtml11.dtd wrt rdf, there's chrome.rdf in the profile, and people have this tendency to look at files. wrt zip's, mozillamail can unzip .zip files for mail users. this would qualify as frontend. should xpi share an icon w/ jar/zip? maybe. it depends on the icon. if it's an installer icon then no, if it's a mozilla archive icon then that'd be an acceptable interim icon for all three. can dtd/rdf use a mozilla generic text icon? yes, it isn't ideal, but it'd be ok.

Comment 200

•

21 years ago

Attachment 129190 [details]: Two thumbs down... without the white border it doesn't look like a polaroid anymore and thus everything I liked about the original is gone. Also I fail to see the benefit of adding the sun; it actually makes the icon seem cluttered in a (frivolous) way. I'm not sure I understand what's wrong with my drop shadow... can you demonstrate graphically? Skewer: How are you doing on the patch? I'm not going to butt in or take over like I have a history of doing, but if you need help or feel overwhelmed just let me know by email and we can work out something. It is impossible to build Mozilla without MSVC due to bug 209664. I despise MSVC so much I wouldn't even warez it let alone purchase it. (I use Dev-C++ for all programming.) Mozilla is supposed to build with GCC but "cl" is hardcoded into Mozilla's makefile.

Comment 201

•

21 years ago

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

Assignee

Comment 202

•

21 years ago

Two thunbs down to all of the proposed JPEG icons. They're all too busy/complex, and I can't make out what the hell they're meant to be in the 16x16 versions. A tree is better. Why the hell does it need to look like a Polaroid, anyway? JPEGs aren't *always* used for photos, you know. They can be used for other complex art, like paintings, CG graphics and even company logos.

Comment 203

•

21 years ago

skewer: Its not a polaroid, its a picture frame. I like the sun, so pffft! :-) Malcom: >However I like some of the improved contrast on the mountains. I'll see if I can >copy some of the contrast changes back to my original "polaroid" icon sometime. That's fine. I don't get why skewer doesn't like the sun, but if you like it, use the sun too :-). Could you also put a white to light grey gradient on the white background of the polaroid so it shows light coming from the top left corner? > A tree is better. The tree all by itself is not only a cliche, and over-used, but it also could represent other things. We'd need at least a sun and a little grass or something with the tree. > They can be used for other complex art,like paintings, CG graphics and even > company logos. Or pr0n :-)

Comment 204

•

21 years ago

I was originally planning to use a tree for PNG. Because PNG is all green and environmentally friendly and efficient and stuff. JPEG is lossy so I don't see it having a tree by itself... JPEG was red when IE associated with it, and now I've got a sunset photo on it so it's still slightly red. It would be counter-intuitive to use green because both IE/WPFV use green for non-JPEG formats. I would be happy to just use attachment 129166 [details] as the JPEG icon, I'm pleased with that one. The polaroid thing really works as an icon. Ultimately, the decision will be made by whoever adds the icons in, not by who complains the most. If it were me I would use attachment 129166 [details]. I still don't see a problem with the overlay drop shadows... I think you have to actually imagine there being something wrong with it to notice a problem. I don't think most people will be examining our icons all that closely. Lack of a drop shadow, they would notice, but whether a corner is sharp or rounded... I doubt it.

Comment 205

•

21 years ago

Attached image Many subtle improvements to JPEG icon (obsolete) — Details

Attachment #129166 - Attachment is obsolete: true

Comment 206

•

21 years ago

Attached image XUL icon w/ rounded shadow (obsolete) — Details

Attachment #129115 - Attachment is obsolete: true

Assignee

•

21 years ago

Attachment #128602 - Attachment mime type: image/x-mswindows-icon → image/x-icon

Updated

Comment 214

•

21 years ago

Attached patch Patch v0.2 (obsolete) — Details — Splinter Review

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

Attachment #129579 - Attachment is obsolete: true

Assignee

Comment 215

•

21 years ago

Attached patch Patch v0.2 - also removes ICO association (obsolete) — Details — Splinter Review

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

Assignee

Comment 216

•

21 years ago

Updated my icon compendium to reflect the consistent icon names I used in the patch, eg. misc-file.ico, image-file.ico, etc. BTW, i renamed html-file.ico to misc-file.ico because, apart from being the default HTML icon, it should be the icon for 'miscellaneous' filetypes too, that can't be easily classified with another icon.

•

21 years ago

Attached file Patch icons (obsolete) — Details

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

Assignee

Comment 221

•

21 years ago

I've applied both versions of patch v0.2 and they work fine on my build, so I'm requesting review and super-review; perhaps a 'rubber stamp' would be more in order for this one though? Be nice if someone changed the status whiteboard to "Need r= and sr=; Requesting rs=;"... how do you become 'sufficiently empowered' to change it, anyway?

Comment 222

•

21 years ago

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

Comment 223

•

21 years ago

Attached file Zipped icons with shadow — Details

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

Assignee

Comment 224

•

21 years ago

> All the drop shadows look just > fine to me, they don't appear to be inconsistent or anything like that. I think they look ****. > If I > ever end up patching this bug I will be using the drop shadow icons. Well, you didn't patch it. I did. And I say use the icons without drop shadows. > Due to the precedent set by Windows Media Player, Internet Explorer, So we're suddenly copying everything that a few major players do now, are we? Mozilla isn't about just copying things; it's about being better, if possible. Icons don't have a 'standard' design, so don't give me this BS about a second drop shadow being the 'standard', it's nothing of the sort. Plenty of icons on my machine have NO drop shadow (Office 2000 icons, Paint Shop Pro icons), and as for the ones you listed. Media Player has no second *alpha* drop shadow, for the overlay, and Internet Explorer has no second drop shadow at all, more like a dark outline, so standard it is not. It comes down to an issue of look and feel, and I far prefer the icons without the second drop shadow, they're less cluttered.

Comment 225

•

21 years ago

I'm going to test and review the patch now... All I'm interested in is the code. We'll let drivers decide about the shadows. I'd rather not be the bad guy (either way, I would be) Remember when this is checked in to put everyone's name who provided icons.

•

21 years ago

Attached patch Patch v0.3 - also removes ICO association (obsolete) — Details — Splinter Review

Built ok and runs fine on my computer.

Attachment #129648 - Attachment is obsolete: true

Assignee

Comment 232

•

21 years ago

Attached patch Patch v0.3 - also removes ICO association (obsolete) — Details — Splinter Review

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

Attachment #129872 - Attachment is obsolete: true

Assignee

Updated

•

21 years ago

Attachment #129873 - Flags: review+

Assignee

Updated

•

21 years ago

Attachment #129648 - Flags: review- → review?

Assignee

Updated

•

21 years ago

Attachment #129648 - Flags: superreview?

Assignee

Updated

•

21 years ago

Attachment #129873 - Flags: superreview?

Attachment #129873 - Flags: review?

Attachment #129873 - Flags: review+

Assignee

Updated

•

21 years ago

Attachment #129648 - Flags: superreview?

Attachment #129648 - Flags: review?

Comment 233

•

21 years ago

>Then why not remove the contributers line and add "Contributers: (see >www.mozilla.org)" or something? Anyway, it's only one or two files :-) I was just mentioning sr might care, since I don't really care. I think we need a better way of showing specific contributions than either CVS blame or through source files. Currently, all we have that most people would see is a contributors list on about:credits, but it doesn't show specifically what they do. I think what exactly contributors do should be more visible than CVS Blame, but of course having a 500 line list of contributors in some source files wouldn't be very good, plus most people wouldn't see it. >Are the spammers really persistent enough to download the Mozilla source to >harvest e-mail addresses? :-) I think I'll leave it as it is, especially as >my e-mail addy is already publically viewable on Bugzilla. I meant more that their spambots can just peruse LXR. I guess there is no point to doing this because we need obfuscating built into LXR, and not rely on people doing it on their own in 8 million different ways. There is a bug about obfuscating emails on LXR: Bug 184456 - lxr.mozilla.org is a spammer's paradise I'm about to review the patch now.

Comment 234

•

21 years ago

Comment on attachment 129873 [details] [diff] [review] Patch v0.3 - also removes ICO association r= Brian Bober (netdragon) Bill: I'm not sure if you would want to review a patch on a different component (personally, I believe this bug should be in XP Apps), but do you mind doing the sr on this since Jag's backlogged with reviews? Jeremy: Everything works great, and applied and compiled perfectly. I was also impressed that the icon was changed back immediately upon opening of Mozilla. :-) I noticed a couple things in the code, but they were insignificant and didn't warrant denying review in my opinion. Upon checkin (after sr= and a=), this is who should be mentioned: Jeremy Morton (Jez): misc-file.ico, image-file.ico, template-file.ico, script-file.ico Jeremy Morton (Jez): Code patch SkewerMZ: gif-file.ico, xml-file.ico Malcolm Scott: jpeg-file.ico Brian Bober (netdragon): xul-file.ico template-window.ico readme.txt Did I miss anyone or something anyone did? (Speak now or forever hold your peace ;-) I had one concern (about scoping) about something you added: SHChangeNotify(SHCNE_ASSOCCHANGED, SHCNF_IDLIST, NULL, NULL); It's a global Windows API function, so it would probably be useful to put it as ::SHChangeNotify so someone reading the source will know its a global scope. The other time it was used in existing code, they did the same thing as you did. I noticed that the file does scope some API functions, but doesn't scope others, but this isn't your fault because it was already like this. It also doesn't scope putPRBoolIntoRegistry, which is another inconsistency, but I imagine they didn't do that because it's a global function within the same C++ file so there is no reason people wouldn't know about it (besides its obviously not a Windows API function). This could cause problems if the function were hidden by a function within the class, but its probably never going to happen, and its the job of whoever changes the code to make sure they don't break existing code. +nsresult putPRBoolIntoRegistry( const char* valueName, + nsIWindowsHooksSettings *prefs, + nsWindowsHooksSettings::getter memFun ) You moved this function before CheckSettings, but could have just put the function prototype at the top of the C++ file and saved a little messiness in the diff. None of these are big enough reasons to deny review in my opinion, just things I noticed and perhaps sr will want these to be dealt with, but in my opinion its overly picky and will just bloat the diff file further. I just didn't want to get yelled at for not noticing them. > It's in a routine that's only run on Windows platforms > because, as far as I can gather, Mozilla doesn't try to associate itself with > filetypes on any other platforms; please tell me if I'm wrong about that. OS/2 might, but that's Mike Kaply's (IBM developer) arena and you don't have to worry about it. Mac might, but I'm not sure because I don't use Macs (plus the icons here wouldn't be liked by picky Mac users, anyway). Therefore, Windows is all we need to worry about. If OS/2 needs to deal with this, it will have to be a separate bug and patched by someone who develops on OS/2.

Attachment #129873 - Flags: superreview?(law)

Attachment #129873 - Flags: superreview?

Attachment #129873 - Flags: review?

Attachment #129873 - Flags: review+

Updated

•

21 years ago

Attachment #129873 - Flags: superreview?(law) → superreview?(jag)

Comment 235

•

21 years ago

Jeremy: I changed the super review to Jag since you heard in #mozilla that Law might not be working on the project anymore and would explain why his queue was so small... If you don't actively seek superreview though, it might be weeks until you have someone look at it. I know this from experience. http://www.mozilla.org/hacking/reviewers.html

Comment 236

•

21 years ago

Of interest: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwxp/html/winxpicons.asp Windows XP icon design guide (just found it)

Assignee

Comment 237

•

21 years ago

Pardon me if I don't listen to Microsoft's every word on how to design icons. They're not particularly wonderful at it themselves, and as that page is for XP, they refuse to acknowledge that 256 color icons suck and stop true color icons displaying on some older versions of Windows.

Comment 238

•

21 years ago

I filed a bug on Cross Platform Icons Guidelines documentation - bug 216364 Jeremy: Can you please mention in that bug about the 256 color icons not being displayed correctly on some systems? Please also provide the Windows version and color depth it was being run at. Thanks.

Comment 239

•

21 years ago

256 color icons aren't necessary for two reasons: 1. WinXP is very pushy about wanting 16-bit color or higher. Very few people will have 256 colors in that OS. 2. Any situation where 256 colors are used the 16-color icons will suffice. If someone is unhappy with seeing 16-color icons they need to get their color depth up to date. It's better to have high-quality in 16-bit than 8-bit at the expense of 16-bit.

Assignee

Comment 240

•

21 years ago

Yep. For once I'm in total agreement with Skewer on this one.

neil@parkwaycc.co.uk

Comment 241

•

21 years ago

If you want to reset the ICO icons exactly once, all you need to do is to check for the existence of the following *value* HKEY_LOCAL_MACHINE\Software\Classes\MozillaICO\DefaultIcon of the key HKEY_LOCAL_MACHINE\SOFTWARE\Mozilla\Desktop and if it exists, remove it and reset the MozillaICO icon ...new versions of mozilla should never create that value, of course...

Comment 242

•

21 years ago

Neil: Cool stuff. Thanks. That's bug 216187 btw.

Comment 243

•

•

21 years ago

Attached image Possible "light red" background — Details

The best I could do in 16 colours.

Assignee

Comment 260

•

21 years ago

Attached image Jez's proposed e-mail icon (obsolete) — Details

Could I propose this as a slightly better e-mail icon than Janet's? It fits in more with the 'Chrome' look for Mozilla. Neil: Mmm, I know it's all subjective, but I don't think that one looks as good as the current 16 color template icon. Bit too... bright and fuzzy.

Comment 261

•

21 years ago

Jez: I like the idea, but at 48x48 (and slightly at 32x32) it looks like the envelope has been scaled up badly. It looks a bit ragged around the borders. Is there a higher res version of the envelope available anywhere? Also, don't forget that the icon will possibly/probably end up used for Firebird as well, where it doesn't fit into the chrome at all.

Comment 262

•

21 years ago

From this point on, my review only applies to the code patch, as an initial code review (meaning you still need sr=), and not the icons. You'll have to find someone else to review the set of icons. Therefore, I'm not going to say anything more about which should be used. Skewer: I'd suggest if you want to give drop shadows a chance, you keep your collection up to date.

Comment 263

•

21 years ago

>Skewer: I asked about you. People think you're an annoying person who >contributes very little to Mozilla and pisses people off a lot. Now I know why. Jeremy: Also, I don't think its appropriate to say something like that to Skewer on Bugzilla. In his defence, he might have a somewhat abrasive attitude at times, but he does have a lot of contributions. Anyway, that's not something that helps this bug any, so its best said through private email. No one manages to go through the Mozilla project without pissing people off from time-to-time. Its the nature of the beast. Let's try to keep things civil and productive.

Assignee

Comment 264

•

21 years ago

> Jez: I like the idea, but at 48x48 (and slightly at 32x32) it looks like the > envelope has been scaled up badly. It looks a bit ragged around the borders. Well, I thought it looked OK, but it's *extremely* difficult to scale icons up (the 48x48 is scaled up slightly), and it's even more difficult to make antialiased borders look good :-) I did the best I could... any other changes seem to make it look worse, not better. Anyone good at touching images up is welcome to try and make them look better. > Is there a higher res version of the envelope available anywhere? No, I nabbed the source off the Mozilla Mail toolbar icons so the 32x32 one is actually the closest to the source size. > Also, don't forget that the icon will possibly/probably end up used for > Firebird as well, where it doesn't fit into the chrome at all. Firebird's a browser. If it were used for anything, it'd be Thunderbird, but seeing as they're trying to get their own identities (as you said, not Chrome), I see no reason why they'd want to use exactly the same icons? They could certainly modify the icons they didn't like. However, this seems more appropriate for Mozilla's Chrome look than the earlier submitted e-mail icon.

Comment 265

•

21 years ago

Drop shadows don't need/won't benefit from my help. If sr knows what it's doing it will ask for drop-shadow icons. If the wrong icons are checked in I will file a new bug to fix the drop shadow.

Comment 266

•

21 years ago

Also, I suggest that sr look at the general tone of the posts for the only person who opposes the drop shadow: Removed that infernal second drop shadow. I think it looks crap. I hate to say it, but your attitude sucks. Skewer: I asked about you. People think you're an annoying person who contributes very little to Mozilla and pisses people off a lot. Now I know why. Brian: This request is beyond a joke. Does this kid know anything about icon design? Or for that matter, the baffling physics that allows a page to cast a shadow, but not an overlay?

Assignee

•

21 years ago

Attached image Jez's slightly redesigned redesigned e-mail icon — Details

Well, I think this is getting a little pedantic, but I've removed the lightish pixels on the 32x32 and 16x16 icons... I'm not gonna change the 48x48 one as they help to smooth out the borders. > The lower edge (and to a lesser extent the top edge) of the envelope in > attachment 130266 [details] (redesigned envelope by Jez) is somewhat jagged at 32x32 No idea why you say that. It looks pretty smooth to me, you'd need to be a hawk to call that 'jagged' :-) > When viewed > against a dark background (like most desktops), those pixels stand out. Most desktops? I always have light backgrounds (I quite like the default WinXP 'Bliss' background), dark ones depress the hell out of me. I would've thought most people had a lightish background for that reason and because light pixels tend to look very ugly on them, but the reverse is not true.

Attachment #130266 - Attachment is obsolete: true

Comment 273

•

21 years ago

Just so I may make my opinion briefly be known: I think an overlay is the wrong approach for a .EML icon, if such an icon truly is needed. If we're trying to work an envelope into the icon, let's have it look like the envelope is part of the icon, not an overlay. An @ sign might be an appropriate overlay but that would look cheap.

Assignee

Comment 274

•

21 years ago

As I was making the icon, that thought passed through my head. But then I thought "this is a document, it's associated with a Mozilla suite program and it's comprised of text, no less." So it's appropriate. Don't fall into the 'IE does this, so we have to' trap.

Assignee

Comment 275

•

21 years ago

Comment on attachment 129873 [details] [diff] [review] Patch v0.3 - also removes ICO association > (From update of attachment 129873 [details] [diff] [review]) > r= Brian Bober (netdragon) Requesting additional r=, from module owner or designated peer.

Attachment #129873 - Flags: review+ → review?

Comment 276

•

21 years ago

Jez: you are going to have to actively seek review on this. module ownership is a mess, atm. If you can manage to get Blake or Jag to review it, you might not need both r= and sr= (only one or the other) since this is not a major patch and one reviewer more knowledgable than I about XPFE should be able to handle it. Anyway, I didn't see an update to the patch. That means this icon won't be installed into the distro. Just edit the makefile and packages-win file for now and don't worry about adding the association to any other parts of the patch unless you want to - we can do that seperately. Nor is there an update for the .zip file. Do that first before seeking review. As for Firebird, we are probably be tossing Seamonkey out the window within the year, and therefore Firebird -> Mozilla in the future. For now, we'd probably use a different set for Firebird as not to confuse people, but in the future if Firebird becomes Mozilla Browser, then I don't see why the icons wouldn't apply. The icons should be independent of selected theme, and personally I believe the blue envelope looks too much like modern. I'd rather see a grey - white gradient. Envelopes are white, not blue. The icons are not theme dependent at the moment, and until then -> XPAPPS so there is no confusion. Of course, I'm leaving Kerz as bug owner. This overlay thing is why I'm glad I'm not a graphic artist. Let's let it rest and the sr can make the decision. You don't have to agree with his or her decision, but the idea is its a mediation type thing. He'll read all the comments and decide based on that. ::currently typing with one hand and the other covered in cookie dough being devoured, surrounded by a pile of college books, wires, boxes and other stuff throughout apartment that hasn't been unpacked yet while thinking about homework already due tomorrow::

Component: Themes → XP Apps

Assignee

Comment 277

•

21 years ago

> If you can manage to get Blake or Jag to review it To that end, does anyone know 'Blake's current e-mail address? The address that I tried from the module owners page seems to be broken now, I got this error back: blakeross@telocity.com host lookup did not complete: retry timeout exceeded > Anyway, I didn't see an update to the patch. That means this icon won't be > installed into the distro. I presume you're talking about the e-mail icon. That's because we haven't settled on one yet. I could easily add it to the patch when one is decided upon, but the reviewer might even decide that it's not worth adding. > personally I believe the blue envelope looks too much like modern. I take your point. Some envelopes are blue, actually, some are pink, etc... they don't *have* to be white :-) Being blue might just distinguish it as being an 'e-mail' envelope and not a 'regular' envelope. But i don't know. Some design a better icon, then. I personally disliked the blue/violet one from Janet. > until then -> XPAPPS so there is no confusion. Of course, I'm > leaving Kerz as bug owner. May I ask why? He seems to have done virtually zero to move this bug along, and maybe is too busy to deal with it, whereas everyone seems to be saying that Jag is more appropriate to be associated with this bug.

Comment 278

•

21 years ago

it doesn't matter who owns it.

Assignee: kerz → jag

QA Contact: sairuh → paw

Comment 279

•

21 years ago

I don't have time to check on this: Do we hook up .eml just like we would for any other extension, or do we have to do something special because its handled by Mailnews? I can check on this in maybe a week. >I presume you're talking about the e-mail icon. That's because we haven't >settled on one yet. As I said before, that is irrelevant. You don't need to settle on an icon to write it into code. You only need to know the name of the icon, which should be file-eml.ico or whatever. >I could easily add it to the patch when one is decided >upon, but the reviewer might even decide that it's not worth adding. It is worth adding because its a file type specific to Mozilla Mail which is part of Seamonkey so it can be installed into the distro location just like the other icons. The icons can always be changed within the .zip file independant of the patch. We definately need an .eml icon. This is not something you need a superreviewer to decide for you. The only thing that I want someone else to decide is about the drop shadows because we need someone unbiased (like timeless ;-) ) to look at all the comments and make a fair decision. >Some design a better icon, then. I personally disliked the blue/violet one >from Janet. Its good enough for now. If people complain that the icon looks too much like its only for the modern theme, we can change it. I want this to make it in by 1.5 or at least be available for drivers by 1.5. If you can figure out how to hook up .eml, then feel free to do it, otherwise just make it so that the icon is installed into the icon directory by editing Makefile and packages-win >May I ask why? He seems to have done virtually zero to move this bug along, >and maybe is too busy to deal with it, whereas everyone seems to be saying that >Jag is more appropriate to be associated with this bug. timeless is right, and you shouldn't just change bug owner without asking. Kerz must want to see the icons or something. Just because he hasn't commented doesn't mean he's not keeping an eye on it. If he doesn't want this bug, he will ask someone to take it. He knows what he's doing and there must be a reason he wants to own this bug.

Assignee

Updated

•

21 years ago

Attachment #129873 - Attachment is obsolete: true

Assignee

Comment 280

•

21 years ago

Attached patch Patch v0.3 - also removes .ICO association (Jez) (obsolete) — Details — Splinter Review

Specifying individual reviewers now.

Assignee

Updated

•

21 years ago

Attachment #129873 - Flags: review?

Robert Accettura [:raccettura]

Assignee

Comment 281

•

21 years ago

Attached file Icons that are required by Patch v0.3 (Jez) (obsolete) — Details

Must unzip these icons into the sourcetree for Patch v0.3 to work.

Attachment #130229 - Attachment is obsolete: true

Comment 282

•

21 years ago

I'm loving the icons on each (much better than earlier). But shouldn't all the icons have something that makes them specifically Mozilla (the light red may not be adequate). Perhaps a tiny lizard, or "Moz" somewhere. Just something to make it clear that it's a file that's associated with Mozilla. I don't think the light red does the job. But I love the icons overall. Just need something to brand them. Perhaps watermark Moz?

•

21 years ago

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

•

21 years ago

Attachment #130838 - Flags: review?(ere) → review?(neil.parkwaycc.co.uk)

neil@parkwaycc.co.uk

Comment 290

•

21 years ago

Comment on attachment 130838 [details] [diff] [review] Patch v0.3 - also removes .ICO association (Jez) >+bin\chrome\icons\default\gif-file.ico >+bin\chrome\icons\default\misc-file.ico >+bin\chrome\icons\default\image-file.ico >+bin\chrome\icons\default\jpeg-file.ico >+bin\chrome\icons\default\script-file.ico >+bin\chrome\icons\default\xml-file.ico >+bin\chrome\icons\default\xul-file.ico Sorry, can't do this until staff decide on the right icons... >+ifneq (,$(filter windows,$(MOZ_WIDGET_TOOLKIT))) >+# Windows icons >+DESKTOP_ICONS = \ I understand it's possible to use += to append only the extra icons. This way if someone adds a new top-level icon it will won't need changing in two places. >+ // Temp. disabling of ICO file handling - >+ // see http://bugzilla.mozilla.org/show_bug.cgi?id=214798 This is no longer necessary.

Attachment #130838 - Flags: review?(neil.parkwaycc.co.uk) → review-

Assignee

Comment 291

•

21 years ago

> Sorry, can't do this until staff decide on the right icons... The point of this bug is to add some appropriate icons for associated filetypes, and not just the functional ability to do so (the original comment says "I believe that there should be a difference between the icon displayed for html documents and graphics, maybe even different icons for types of images."). If this is the attitude, then I suggest, with a heavy heart, that you change this bug to WONTFIX. That said, I'm not quite sure why the Mozilla people seem to be so worried about branding 'going wrong' unless approved by some high-up committee... I think a mountain is being made of a molehill here.

•

21 years ago

Attachment #136863 - Flags: review?(neil.parkwaycc.co.uk)

Az

Updated

•

21 years ago

Flags: blocking1.6?

chris hofmann

Comment 295

•

21 years ago

lets finish this work in 1.7. 1.6-

Flags: blocking1.6? → blocking1.6-

Assignee

Comment 296

•

21 years ago

Attached patch Patch v0.5 - doesn't remove .ICO association (obsolete) — Details — Splinter Review

Patch with correct Makefile.in.

Attachment #136863 - Attachment is obsolete: true

Assignee

Updated

•

21 years ago

Attachment #136863 - Flags: review?(neil.parkwaycc.co.uk)

Assignee

Updated

Updated

•

21 years ago

Attachment #140601 - Attachment description: Icons that are required to make a patch for this bug meaningful → Icons that are required to make patch v0.6 for this bug meaningful

Assignee

Updated

•

21 years ago

Attachment #140601 - Attachment description: Icons that are required to make patch v0.6 for this bug meaningful → Icons that are required to make Patch v0.6 meaningful

Assignee

Updated

•

21 years ago

Attachment #137336 - Flags: review?(neil.parkwaycc.co.uk)

Assignee

Comment 302

•

21 years ago

Attached patch Patch v0.6 — Details — Splinter Review

> Well in that case I would like to see separate misc-file and html-file icons Alright. Although I do think the HTML and misc file icons should be the same. > do that and you'll get r=me, at least on the parts where it counts... Ah, the icons? :-)

Attachment #137336 - Attachment is obsolete: true

Assignee

Updated

•

21 years ago

Attachment #140604 - Flags: review?(neil.parkwaycc.co.uk)

Jason Kersey

Comment 303

•

21 years ago

mozilla.org has a branding committee, who is now in charge of artwork that goes into the tree. Please consult them before checking this in. I think bart would know who best to contact for this specific bug (bart@mozilla.org).

neil@parkwaycc.co.uk

Comment 304

•

21 years ago

Comment on attachment 140604 [details] [diff] [review] Patch v0.6 >+ xhtml( xhtmExts, "MozillaXHTML", "XHTML Document", "", "misc-file.ico"), Almost right but I think this should be html-file.ico

Attachment #140604 - Flags: review?(neil.parkwaycc.co.uk) → review+

Assignee

Comment 305

•

21 years ago

> Almost right but I think this should be html-file.ico No, the whole point is that XHTML is *NOT* HTML. It's a misc filetype, so I think that's a more appropriate icon. Besides, - The misc-file icon is the same as the HTML one anyway. - We need *something* to use that icon :-) Thanks for the r+, anyway.

Assignee

Updated

•

21 years ago

Attachment #140604 - Flags: superreview?(jag)

Jason Kersey

Comment 306

•

21 years ago

Have you emailed bart and gotten a response? If you charge through and get reviews from people who aren't even paying attention, and check in unreviewed icons, we're going to have a problem.

jag (Peter Annema)

Comment 307

•

21 years ago

It sounds like you need to get an r= on the artwork from bart. Can you request r= from him on the artwork?

jag (Peter Annema)

Comment 308

•

21 years ago

Comment on attachment 140604 [details] [diff] [review] Patch v0.6 sr=jag. This looks good to me, but don't check this in until the artwork has been approved.

Attachment #140604 - Flags: superreview?(jag) → superreview+

Assignee

Updated

•

•

21 years ago

checked in

Status: NEW → RESOLVED

Closed: 21 years ago

Resolution: --- → FIXED

Constantine A. Murenin

Updated

•

21 years ago

OS: Windows 95 → Windows XP

Samir L. Boulema

Updated

•

21 years ago

Blocks: 226603

Asa Dotzler [:asa]

Updated

•

21 years ago

Flags: blocking1.7b?

Myk Melez [:myk] [@mykmelez]

Assignee

•

21 years ago

Keywords: relnote

Updated

•

20 years ago

Product: Core → Mozilla Application Suite