We need to base our complete icon set(s) on the new SeaMonkey logo, esp. those icons that still feature the old "m" logo. This needs to be done for Windows, Linux, Mac and OS/2, and should probably fix a few other things as bug 105672 along the way.

It might be a good idea to adopt something like the set of bug 88393 to the new SeaMonkey logo and use it for for all platforms...

Current .icns files provided by m.o contain a range of different icon sizes and respective bit masks.

But our current mozilla.icns provides a smaller set of icons - the small icons will be autocreated by the system if needed (this may cost quality, of course).

Overview over the icons contained in our other .icns files (command.icns, component.icns, html.icns, plugin.icns, pref.icns, text.icns), but without 8bit/4bit and tiny icons. We even reference more files (e.g. image.icns) that we don't provide!

That icon set would fit well if themed for all our platforms if themed for SeaMonkey instead of Mozilla... I just wonder if we have no different icons for mail/composer/etc. on Mac, i.e. in that icon set... CCing Simon, who made the current Mac icon set in bug 88393 - would it be possible to do an icon set in that style based on the SeaMonkey logo instead the "m", for all platforms, and with all icons we provide at the moment (components, etc.)?

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

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

I assume the window icons will need to wait until the new theme is finished, but how about something like this for Windows filetype icons? The top row consists of what we have now, and the bottom row consists of the icons recolored for SeaMonkey (and with the SeaMonkey logo replacing the Mozilla one, of course).

The mockup looks good, and I'd be happy to go with that design but we really need those in multiple sizes, up to at least 48x48, maybe even 128x128, so that a file of such a type stored on the desktop still looks as it should on that platform. Windows Vista wants 48x48 variants AFAIK, Mac even 128x128 IIRC. So we probably need to go in the direction of redoing all icons as SVGs and then create smaller versions as needed, which may even look a bit differently than the big ones due to simplification and cleanup. And I don't think we need to wait on any theme icons, as even though the window icons should fit the default theme style (which we know now with the primary toolbar icons being there), the icons are not dependent on the theme, they also don't change if you change the theme.

(In reply to comment #9) > The mockup looks good, and I'd be happy to go with that design but we really > need those in multiple sizes, up to at least 48x48, maybe even 128x128, so that > a file of such a type stored on the desktop still looks as it should on that > platform. Windows Vista wants 48x48 variants AFAIK, Mac even 128x128 IIRC. > So we probably need to go in the direction of redoing all icons as SVGs and > then create smaller versions as needed, which may even look a bit differently > than the big ones due to simplification and cleanup. Sure, I can make filetype icons up to 48x48 pixels, since the existing icons already have graphics in those sizes to work with. I have attached 48x48 and 16x16 mockups as examples. Unfortunately, though, I don't know if I'll be able to help with sizes beyond that. I have very little experience with vector graphics, so it would take quite a while before I could even recreate the existing icons, and I was hoping to have these done for 1.1 if the Council agrees with the design. Then again, this all depends on whether we will continue using a platform-dependent set of icons or switch to a universal set for all platforms. If the former is chosen, I could still create icons for Windows in the style of the mockups that I created, since 48x48 would be the maximum required size. If the latter is chosen, it would probably be best to find someone who can create new ones from scratch using SVGs, since I'm not sure if Mac users would want Windows-style icons. I wish I could be of more help, but I'm more of a programmer than a graphics person. :) > And I don't think we need to wait on any theme icons, as even though the window > icons should fit the default theme style (which we know now with the primary > toolbar icons being there), the icons are not dependent on the theme, they also > don't change if you change the theme. Good point. However, those icons probably need more of an overhaul since they don't even have 48x48 sizes and are mostly based on Classic. I'll take a look and see if I can come up with anything, though.

(In reply to comment #11) > Created an attachment (id=242059) [edit] > main-windows.ico Hmm, that doesn't identify SeaMonkey for me at all... KidReefer from the Mozillazine forums is working on a good set of icons though, his early concepts look promising to me, let's see with what he comes up in the end...

KaiRo, could you please provide a link to the thread where these concepts are going on, or an actual post, et-al?

No, I can't link you my personal message inbox on Mozillazine forums, sorry. We'll surely put them up for discussion here and/or in the SeaMonkey developer newsgroup once they're at a state I really do like.

Here is the full set of filetype icons that I described above (based on the existing icon set from bug 99380). Each icon contains 3 sizes (16x16, 32x32, and 48x48) in 3 color depths (16 colors, 256 colors, and true color w/ alpha transparency). I'm not sure whether or not KidReefer's icon set includes filetype icons, but if so, maybe these icons could still be used for 1.1 if his aren't completed in time.

(In reply to comment #15) > Created an attachment (id=242259) [edit] > Windows filetype icon set > > Here is the full set of filetype icons that I described above (based on the > existing icon set from bug 99380). Each icon contains 3 sizes (16x16, 32x32, > and 48x48) in 3 color depths (16 colors, 256 colors, and true color w/ alpha > transparency), I like these.

Comment on attachment 242259 [details] Windows filetype icon set (checked in, trunk+branch) Let's get those in. Any SeaMonkey-branded file icons are surely better than the Mozilla-branded ones we have right now.

It seems someone missed updating the main-window.ico, messengerWindow.ico, nd other Seamonkey Application window and other icons. Could this be fixed in v1.1 and v2.0? Thank you

Nobody has missed those, they just haven't been generated yet. We'd badly need a set of icons for all those, that's why the bug is still open. In the screen shot it's hard to see, but the "suggested mail icon" is too hard to visually detect apart from the normal SeaMonkey icon at 16x16, it seems. We really want that fixed for 2.0, it's too late in any case for 1.1.x though.

JW vanLohuizen: Maybe if you made the envelope bigger... it would cover more of the 'monkey', but it would be easier to realize what it means.

(In reply to comment #19) > In the screen shot it's hard to see, but the "suggested mail icon" is too hard > to visually detect apart from the normal SeaMonkey icon at 16x16, it seems. > > We really want that fixed for 2.0, it's too late in any case for 1.1.x though. > Would it be added for a future release of 1.1.x if I uploaded my main-window.ico file and if I could make messengerWindow.ico that is more recognisable? I got the mail envelope from FOOOD's Icons so it would have to get his approval to use that part of the icon.

I don't think we will do such a change any more in any 1.1.x release. What we'd need for 2.0 though is a full set of icons, that ideally would fit with our new default theme, all the icons must have all needed resolutions and color depths (like seamonkey.ico), and the copyrights for all imagery must be assigned to the SeaMonkey Project / Mozilla Foundation, and we'll set them under the tri-license. It may be best to actually discuss actually proposed icons in the newsgroup / mailing list though.

(In reply to comment #22) > I don't think we will do such a change any more in any 1.1.x release. > > What we'd need for 2.0 though is a full set of icons, that ideally would fit > with our new default theme, all the icons must have all needed resolutions and > color depths (like seamonkey.ico), and the copyrights for all imagery must be > assigned to the SeaMonkey Project / Mozilla Foundation, and we'll set them > under the tri-license. > > It may be best to actually discuss actually proposed icons in the newsgroup / > mailing list though. > OK

I just posted to my blog about still needing window icons here, see http://home.kairo.at/blog/2007-08/icons_for_seamonkey_windows_needed Please don't post icon proposals or preview designs here in the bug, but (as mentioned in the blog) post links to them to the SeaMonkey development newsgroup, where we can discuss them way better. We should only come back to this bug when we have a design that we feel comfortable with.

Here's the Makefile patch to go along with the icons I'll attach in a minute. I have found that our new icons for 16x16 are just scaled down versions of the 32x32 icons, and GTK2 does a good job of smoothing borders when scaling them down, so 16x16 actually looks better on Linux if we only provide a 32x32 version (due to xpm not supporting Alpha). Because of that, I'm removing small icons for GTK in this patch. The rest if just renaming of JSConsole to what we're actually using now and adding abList.

Comment on attachment 291669 [details] [diff] [review] Makefile patch, v1 (checked in) >-DESKTOP_ICONS_SMALL=$(patsubst %,%16,$(DESKTOP_ICONS)) >+DESKTOP_ICONS_SMALL= > endif > > DESKTOP_ICON_FILES = $(addsuffix $(ICON_SUFFIX), $(DESKTOP_ICONS) $(DESKTOP_ICONS_SMALL)) Why not just remove DESKTOP_ICONS_SMALL completely?

At http://resources.kairo.at/mozilla/ui/bug321927-icons-v1.zip you can find the new icons from spinello, who agreed to license them in our tri-license, including the SVGs. (Unfortunately I couldn't attach the full .zip here, as it's too big, attaching only the GTK portion so we have an attachment to track here - please review the full package linked in this comment.) The ZIP file contains Windows, GTK and SVG versions, we still need to care to fix up OS/2 and Mac afterwards. The SVG versions aren't actively used anywhere but are a good base for anyone to create further icons from if needed. To apply, please remove suite/branding/icons/gtk/*.xpm and suite/branding/icons/windows/*indow.ico and unpack this file into suite/branding/ Also apply the Makefile patch to have this fully working. [obsoleting all attachments that aren't current or weren't actually checked in to ease orientation]

(In reply to comment #27) > Why not just remove DESKTOP_ICONS_SMALL completely? We probably could do that, I just wasn't sure if we still might want/need it for something - probably not, though.

> http://resources.kairo.at/mozilla/ui/bug321927-icons-v1.zip Oh no, not these icons, for heaven's sake, anything but that. I think Seamonkey's new default icons are nice (see attached screenshot). I think Seamonkey was on the right track and we should keep the icons that haven been used in the nightly builds so far.

(In reply to comment #30) > I think Seamonkey's new default icons are nice (see attached screenshot). We're not changing the theme icons here, but the icons the OS (windows in your case) uses to identify our windows, i.e. in the upper left on your image and on the task bar. Again, theme icons stay unchanged with any work in this bug. Adjusting the summary to make this a bit clearer.

Thanks Robert for the explanation. I'm reassured. If you need a new xpm or png icon for the task and title bars, I can help you.

Comment on attachment 291672 [details] new GTK icons, v1 (checked in) The full .zip has an abListWindow.ico - spurious? Should we be shipping a ChatZilla icon? If it ships its own icon as an extension won't that override ours?

(In reply to comment #33) > (From update of attachment 291672 [details]) > The full .zip has an abListWindow.ico - spurious? oops. That one is the correct one we want to use and needs to be renamed to ablistWindow.ico, the other one needs to be killed. > Should we be shipping a ChatZilla icon? If it ships its own icon as an > extension won't that override ours? Right, we should not ship the chatzilla-window icons (currently), we should leave them out for this patch.

Comment on attachment 291672 [details] new GTK icons, v1 (checked in) With abListWindow.ico replacing ablistWindow.ico

Comment on attachment 291669 [details] [diff] [review] Makefile patch, v1 (checked in) With DESKTOP_ICONS_SMALL removed.

Comment on attachment 291669 [details] [diff] [review] Makefile patch, v1 (checked in) Bah, why did Bugzilla ever reorder the flag symbols in the first place?

Comment on attachment 291669 [details] [diff] [review] Makefile patch, v1 (checked in) checked in with DESKTOP_ICONS_SMALL removed.

Comment on attachment 291672 [details] new GTK icons, v1 (checked in) Checked in GTK/Windows/SVG icons. Leaving the bug open to update OS/2 icons and figure out what to do with Mac icons, as things work differently there.

Mark reminded me that we also need installer changes along with this - here they are :)

Comment on attachment 292093 [details] [diff] [review] installer changes to go with new window icons (checked in) installer/packaging changes checked in.

One of these changes probably caused l10n sea-win32-tbox burning (for 2 cycles at the moment)

(In reply to comment #42) > One of these changes probably caused l10n sea-win32-tbox burning (for 2 cycles > at the moment) Looks like l10n-stage doesn't get cleaned in non-clobber builds and overwriting jsconsole.ico with JSConsole.ico is problematic somehow... I killed l10n-stage from the tinderbox, I hope it works now.

(In reply to comment #43) > Looks like l10n-stage doesn't get cleaned in non-clobber builds and overwriting > jsconsole.ico with JSConsole.ico is problematic somehow... I killed l10n-stage > from the tinderbox, I hope it works now. Yes, this fixed the problem.

(In reply to comment #39) > Leaving the bug open to update OS/2 icons Heiko Nitzsche converted them to OS/2 format: http://heikon.home.tlink.de/temp/sm_os2_icons.zip I checked that they work fine, so that counts as r+. Should I just check them in or does somebody want to sr them first?

(In reply to comment #34) > Right, we should not ship the chatzilla-window icons (currently), we should > leave them out for this patch. Should those not get CVS removed now?

(In reply to comment #45) > Heiko Nitzsche converted them to OS/2 format: > http://heikon.home.tlink.de/temp/sm_os2_icons.zip > I checked that they work fine, so that counts as r+. Should I just check them > in or does somebody want to sr them first? Feel free to check them in, we can't check if they're correct or such anyways ;-) Thanks for caring about that! (In reply to comment #46) > (In reply to comment #34) > > Right, we should not ship the chatzilla-window icons (currently), we should > > leave them out for this patch. > > Should those not get CVS removed now? According to Standard8, we'll leave them for now and wait for what ChatZilla is going to do about their icon. They're not packaged by the Makefile anymore though.

OK, OS/2 icons checked in. JSConsoleWindow.ico was a bit difficult to handle on a case insensitive filesystem, but I think all files are now correct in CVS.

Hmm, the Mac and Windows tinderboxes didn't like that file, either. (Yay, first time I got a tinderbox red!) KaiRo could you please remove and update mozilla/suite/branding/icons/os2/JSConsoleWindow.ico on both of them (manually)?

(In reply to comment #49) > Hmm, the Mac and Windows tinderboxes didn't like that file, either. (Yay, first > time I got a tinderbox red!) > > KaiRo could you please remove and update > mozilla/suite/branding/icons/os2/JSConsoleWindow.ico on both of them > (manually)? Needs a bit more done, actually, but I know what to do on both tinderboxen and just did clobber/remove all necessary files/directories. The other solution would have been to trigger a clobber build, but this one is faster ;-)

Here's the current set of mac .icns files in suite/branding/icons/mac. From top to bottom: pref.icns, component.icns, text.icns, plugin.icns and command.icns. As you can see, they all need to be rebranded ;-) I haven't looked into this that much, but If you look at suite/app/macbuild/Contents/Info.plist.in you can see what file types those icons are associated with. Note that .html probably require that SeaMonkey is set as the default browser (which it never asks on mac, we'll need to port some Firefox/toolkit code in order to make SeaMonkey ask).

I do get the build error: make[5]: Entering directory `/c/Mozilla/sm1/obj-i686-pc-mingw32/suite/branding' make[5]: *** No rule to make target `icons/windows/JSConsoleWindow.ico', needed by `libs'. Stop. my .mozconfig file: mk_add_options MOZ_CO_PROJECT=suite mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj-@CONFIG_GUESS@ ac_add_options --enable-debug ac_add_options --enable-application=suite ac_add_options --disable-optimize Any idea what's wrong?

(In reply to comment #52) > make[5]: *** No rule to make target `icons/windows/JSConsoleWindow.ico', needed > by `libs'. Stop. Try deleting icons/ and check it out again, you might just have a problem with your file system being case-insensitive but we did change the case of that file name.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050801 SeaMonkey/2.0a1pre Do these icons apply to both themes, or only Default? I use Modern on Linux, and most of my icons are identical to the GTK icons in attachment 291672 [details], but the Chatzilla window icon is markedly different. (I see cZ in dark-bordered white letters, and no blue disc.) This bug was fixed on branch more than a year ago, and the last comment is more than 3 months old. I wonder what (other than just plain old forgetting) is preventing it from getting fixed on Trunk.

AFAICS the Mac icons are still missing.

Right, Mac icons are still non-fixed. But maybe this is something we should do in a new bug.

Marking FIXED so things are cleaner, Mac icons have been split off as bug 441061.