Closed Bug 88393 Opened 23 years ago Closed 21 years ago

Check in a high-resolution application and document icon suite for Mac OS X

Categories

(SeaMonkey :: Build Config, enhancement)

Product:
SeaMonkey
Component:
Build Config
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hsivonen, Assigned: lordpixel)

References

Details

(Keywords: fixed1.4, verifyme)

Attachments

(2 files, 3 obsolete files)

Incorporates changes to Info.plist, and Makefile.in changes required to deploy the new icns files
7.61 KB, patch
timeless
: review+
sfraser_bugs
: superreview+
Details | Diff | Splinter Review
Remove cp *.icns, because rsync command a few lines up will copy the icons, so long as I move them to the right place in CVS
700 bytes, patch
timeless
: review+
sfraser_bugs
: superreview+
asa
: approval1.4+
Details | Diff | Splinter Review
(Spun off bug 58228) Documents that belong to Mozilla have 32px*32px icons. On Mac OS X, high-resolution icons are expected. I think it is worthwhile to investigate whether Mac OS X comes with suitable generic icons. If there are no suitable generic icons, new icons are needed.
Blocks: icons
I would be posting this to bug 58228, but it's best to leave sleeping lizards lie :-) http://home.alphalink.com.au/~cltan/mozilla/ Contains: 1 application icon, 1 document icon, 1 bookmark icon. Icons are at 128x128, document and bookmark icons are also at 32x32. Contains traces of the red Mozilla icon, may be incompatible with the MPL. I reckon that the document icons should be in the same bug with the application icon, at least eventually, because we want the icons to be part of a set with the same graphic styles, right? Icons which we'll want to consider: - Application icon - Text document icon - Bookmark icon - Plug-in icon - Shared library icon - Command-line argument icon And maybe - Downloading icon? - Generic icon?
All of the current file icons need to be replaced. This includes most of the ones you listed, and also binary files ("BiNA"), registry files ("REGS") and a few others.
I was thinking that we could take the opportunity to "clean up" the file mappings we use in Mozilla... last time I checked, there were a few icons with old-style graphics (the blue angular thing), which I guess nobody is supposed to see? Which means they aren't meant to be used. Things like certificate files... do we actually use them or just use the generic icon? Etc.
The first priority is to produce a good icon set for OS X based on the current icon set. What I need to do this is access to the source files used to produce the current Mac OS icon set. (I hope the icons weren't just drawn as bitmaps...I need the original vector art, which I'm sure exists.) Give me the original art, I'll muck about in Iconographer and produce the proper OS X icons. Also, I've noticed there are many Mozilla files that have no icons, but should...Component Registry, all the ".jar"s, ".xpt"s, ".js"s, ".html"s, ".rdf"s, ".tbl"s, ".properties"s, ".txt"s, ".css"s, ".xul"s, ".xml"s, ".gif"s, ".jpg"s and ".src"s. Where is the documentation for all these file types in Mozilla? Where is the list of Mac OS types and creators for all these? We need to polish this stuff up...it's easy. Entirely new icon sets are an enhancement...we need to be able to publish the existing icon set to all platforms optimally. So, give us access to the source materials and we'll go to town.
Just make sure when you release your icons that they are a Moz-compatible license. From what was listed in the application icon bug, GPL isn't compatible with Moz. What the correct license IS I'm not sure about. - Adam
I'm not interested in creating a new icon set, all I want is the original materials used to make the *existing* icon set so I can make a proper set for Mac OS X. That doesn't require GPL, MPL, or my butt's PL for that matter.
Well, apparently Mozilla's icons issue from a tame black hole. I've asked nicely here on the newsgroups and on #mozillazine, and hear nothing but absolute silence about this application's icon set. Phooey. Nonsense.
Sorry about the delay. Repeating here what I said in the ng: The graphical element that indicates the Mozillaness in the old icons is obsolete. It dates from the era before the Modern 1 theme. I think new Mac OS X icons should contain a small version of the app icon 'M' instead an the Mozillaness indicator. The 'M' graphic can be copied from the app icon, but a canonical Mac OS X document icon template is needed. I think there are two ways to get one: 1) From Apple, if an icon template is available as MPL compatible sample code. I'm not sure whether the Apple sample code license covers the icons that come with Apple sample code. If is does cover them, we might be able to use an Apple-provided icon as a starting point. This requires checking the legal stuff, though: * Does the sample code license cover icons? * Is the Apple sample code license compatible with MPL? I suppose it is, but IANAL. IIRC, lordpixel has investigated the issue. 2) If we can't get a legally unencumbered icon template from Apple, we need to develop one from scratch. It should be: * Recognizable as a document icon from the user point of view. * But different enough from from Apple's icons from Apple Legal point of view.
About the icons at http://home.alphalink.com.au/~cltan/mozilla/ - I think it's a good idea, from a UI perspective. The big M is bad. Here's why: An icon, by definition is "an image, picture or symbol representing a concept". A fire-breathing lizard is a good example. An M is a bad example. An M doens't represent anything. It's a two-step cognative process to see the symbol, "M", then think, "Oh, that's M as in Mozilla." I keep my Mozilla icon right next to my Mail icon on the Dock, and often make the UI mistake of selecting the M when I want Mail. Text should only be used on icons to disambiguate a symbol - like a street sign that says, "Dead End" (the yellow diamond being the symbol saying "attention - important driving information"). See Shneiderman, Ben. Designing The User Interface, 3rd. Ed., pp. 208-210. Terrance, can you put "licensed under the MPL" on the page with your icons so people could consider it?
Unfortunately, the icons aren't mine to licence... I've used the Mozilla lizard image, which isn't under a free software licence (yet... see bug 28028). Also raised was the fact that I've used the Apple generic icons as a template, although I don't really see that as being too much of an impediment (I'm sure Apple have given developers free rein to use the generic icons as templates).
Is there anyone who's working on the identity package for Mozilla in general irrespective of platform? They're who I need to work with on this. If not, is this an effort I should initiate? I can certainly hook up with a designer and come up with some real specs and designs and stuff.
I'm starting an effort to formalize an effort to revise the parts of Mozilla's appearance outside themes, such as the icon suite, the installer, the splash screen, and the Profile Manager dialog. I've started a web page with some initial ideas and bug links at [http://greg.tcp.com/mozilla/ui/Outside/introduction.html]. I welcome any and all comments on it.
Blocks: 102998
-> pinkerton
Assignee: pchen → pinkerton
how about just starting with the 4.x icons and making them more high-res and doing one set badged for mozilla and another set badged for nscp? i wish i could draw :(
Status: NEW → ASSIGNED
Are you talking about the *Netscape* 4.x icons? That might be fine for Netscape builds, but not for Mozilla, don't you think?
right, but they're only 'netscape' because they have a nscp badge. make two sets, one with a mozilla badge, the other with a nscp badge. use the existing 4.x icons as a starting point. (isn't that what i just said?)
cc'ing marlon on this, since he can draw and I sure as heck can't. marlon, any free time to whip up som cool document icons for moz and nscp?
actually that came to mind when i was doing some other aqua stuff. i will definitely try to get those icons ready soon
Isn't anyone remotely interested in approaching this in a formal and well-managed way? Have I written my specs draft for naught? Sheesh.
Greg, I think your effort is the right one, but it wouldn't make sense to do all the effort if it's just going to be ignored in the end, no matter how good it is (yeah, like that's never happened before). I think some sort of 'official' buy-in is necessary for your effort to really take flight.
Adding bug 28028 as a dependency, assuming the lizzard is to be used in one way or another.
Depends on: 28028
*** Bug 117521 has been marked as a duplicate of this bug. ***
I've created a Mozilla Mac OS X icon set for my personal use. After receiving a lot of positive feedback I'm currently thinking about putting them out under the mpl, gpl or any other license you want. I've used the M instead of a lizard partly because of licensing issues and partly because the lizard shape makes it difficult to create a good looking icon set: Basically I love the blocky, industrial identity of Mozilla but I'm not sure as to whether anybody has ever drawn the Mozilla.org lizard as a whole, not just the head and the upper body. Using just the head in an icon often creates the disgusting appearance of a beheaded lizard, especially since it has a bloody red color. I'm well aware of the fact that text in an icon should be avoided. You can even take a look at my Icon Design Workshop (in German: http://www.theparallax.org/wissen/grafik/icondesign/index.html) for some of my suggestions on that issue. - But I don’t think that the use of the M creates any usability problems. The special capital M is a kind of logo that stands for Mozilla, not a letter that can be either used for Mail, Management, Multimedia or whatever. All Microsoft Mac products use a logo character as an icon and about 25 percent of all applications (Hotline, Unreal, BBEdit, etc.) do the same. While it is extremely bad design to use a word like "color" in an icon instead of just showing some colors (see this picture: http://www.theparallax.org/wissen/grafik/icondesign/texticons.gif), I see absolutely no problem at all in the use of the capital Mozilla M logo. -- Personal taste put aside... The Picture just shows the basic design direction I have taken. I've not been using any existing artwork (besides the logo) so there would be no licensing issues. The icon set is not completed yet but I'd be happy to produce any Icon that is needed. I have two questions: * I'm planning on using the Mozilla license. Would that be okay? * Which icons do you want exactly? Please list all document categories that need an icon. – For example: "Program component," "Preferences," etc. – I don’t have the time to create individual icons for each and every member of a category. (.rdf, .jar, .shlb, .xpt, etc.) Please give me some feedback. Thanks, Simon. Here's the image: http://www.theparallax.net/sd/proposals/Mozilla-Icons.jpg
very nice. sure, mozilla license is great ;) my only concern is that the 'chat' icons look a lot like those from msn messenger. msft might be angry we're stealing their artwork (i know you didn't, just it looks very similar).
The two people were actually intended to stand for "Profile conversion" and "Profile Settings". But you're right. They look quite similar. Here's an image of the msn messenger symbol: http://www.microsoft.com/mac/images/officex/articles/bluepeople.gif
The icon set is now updated, more polished and complete, contains descriptions and licensing information: http://www.theparallax.org/sd/proposals/mozilla/icons.html - It's still not ready, though.
not sure why this landed on my plate -> marlon
Assignee: pinkerton → marlon
Status: ASSIGNED → NEW
(Is this bug really still qawanted? What QA does it need?)
Well, how about including the icons now and asking for QA later?
Simon, how is your icon set progressing? Since your set doesn't seem to include a red lizard, I don't think it depends on bug 28028 any more. There should be no impediment to getting them checked in.
Severity: normal → enhancement
Keywords: qawanted
Summary: Need a high-resolution document icon for Mac OS X → Check in a high-resolution application and document icon suite for OS X
Summary: Check in a high-resolution application and document icon suite for OS X → Check in a high-resolution application and document icon suite for Mac OS X
Simon, to respond to the last paragraph in your comment 23, checking Mozilla's plist yields the following list of supported (but missing) .icns files: 129, Text File 130, Preferences 131, Plugin 142, Command Line File 138, Shared Library 139, Binary File 128.icns is, of course, the application icon.
I've been quite busy lately so I wasn't able refine the icon set further. As this bug is apparently now being resolved I'm trying my best to deliver the final versions as soon as possible. I'm not at my computer the following week so that will be probably around the 5th of August. Greg, thank you for the List - that will be helpful.
Cool. Note that, since those have CFBundleTypeIconFile strings defined, you can just create the appropriately named .icns files, drop them in Mozilla.app/Resources, and they'll start working automagically. I should note that there is an additional CFBundleTypeExtensions for "Image File" that presently lacks a CFBundleTypeIconFile string, though I suppose it could be easily added.
I've been working on an image file icon; you can see a version online although I'm not really happy with how it worked out. (http://www.theparallax.org/sd/gallery/interface/picture.png). The image icon you are talking about would represent all various image formats generically, right? Additionally, I've completely redesigned the Address Book icon to look more like the little background image in the upper left corner of the Address Book window (http://www.theparallax.org/sd/gallery/interface/moz-addressbook.png). I guess that different icons for the different parts of the application will be useless, at least for now. The icons you listed are a good start, anyway. Let's see what we can do after that has been resolved...
Simon, yes; the image file would appear to represent files with .jpeg. .jpg, .png. .gif. and .mng extensions.
Simon, you might take a look at my new bug 163175. The metadata for OS 9 and OS X builds are way apart.
Greg, Simon, how does the metadata bug influence the Mozilla for OSX getting high resolution icons?
A while back I took Simon's icons and made .icns files based on them that can be put right into the Resources folder and work straight away. Here they are. The only problem with them is that the 48px version's mask needs some adjustment, I think. All the reduced-size versions and masks probably need some QA in general to ensure everything looks the way they should.
I realized the 48px 8-bit mask was wrong on 129.incs. Here's the whole suite again, with that problem fixed. Simon, I think it would be best to check these in as they are now, and then continue to work to add the other icons. Would that be okay with you?
Attachment #97413 - Attachment is obsolete: true
I am trying my best but I'm currently moving to another city and everything has to normalize a little bit again. I don’t like to release unfinished work but I'll probably have some time today or tomorrow.
Simon: how'd your move go? Any progress on the icon set?
*** Bug 157829 has been marked as a duplicate of this bug. ***
Ok, I'm jumping in the water with a few points: the naming convention using numbers (128.icns, etc.) in the carbon cfm builds was designed so that we were able to use traditional 'icns' resources and be compatible with OS9 and OSX at the same time. The plist parser is smart enough to load binary resources if there is no .icns file with that name in the Contents/Resources folder. Up until mozilla 1.2.1 the application icon was stored in a "modern" icns file named 128.icns while all the other icons (129, etc.) were still "old" resources stored in the resource fork of the binary. With Mach-o, we now live in a better world :-) We can forget about resource forks. All icons will be stored in .icns files inside Mozilla.app/Contents/Resources/ So, all this to say that icns files in their release form should now have more "meaningful" names such as the data type they actually represent, instead of numbers. Based on the data types mozilla handles (not all of them are listed in info.Plist yet), I suggest the following: html.icns text.icns plugin.icns pref.icns sharedlib.icns command.icns (command line files, could be obsolete) binary.icns image.icns (or should we let the OS handle this and stamp a Preview/Quicktime icon to images saved from Mozilla...) We could keep the name mozilla.icns for the app's icon, as most apps do. Once approved, such files should be checked in (as binary of course) individually inside mozilla/xpfe/bootstrap/macbuild/Contents/Resources and the info.Plist file should be updated accordingly. (it currently only refers to fileHtmml.icns and fileBookmark.icns) That will ensure their automatic inclusion in the build without having to touch the build or packaging script(s)
Since we're not case, whitespace, or length-limited in OS X, no need to shorten filenames unnecessarily. We can use, for example: Plug-in.icns Preferences.icns Shared library.icns Command-line file.icns
would whitespace in filenames cause any problems with the mach-o build system? (i seem to recall hearing about build problems if any of the folder names had whitespace, but i might be misremembering.)
This probably belongs on Build Config, not XP Apps. S. Dorner has asked me via e-mail what sort of files the Binary Files icon will be used for. JJ, do you know the answer to that?
Component: XP Apps → Build Config
Also, should we change your HTML.icns to Mark-up.icns, perhaps, to cover HTML, XHTML, XML, etc., and leave Text.icns to cover other plain text files?
icns file names: files will be checked in in cvs, so we don't want whitespaces nor capitalization. In addition, these files are not visible to the user (just hackers), so we don't really need fancy names. Let's keep them short and simple. Again, to match what's done in some of Apple's apps, we could use mozilla-html.icns, mozilla-plugin.icns, mozilla-pref.icns, etc. but my preference is still to keep them to just the data type, whether it's short (text.icns, pref.icns) or long (image.icns, plugin.icns). These are explicit enough to whomever pokes inside the application bundle. binary.icns: this if for mozilla generated files such as what you can find inside a user profile: .mab, .bag, .na2, .msf, .sdb, .regs, .dat (These type will be added to Info.plist) markup.icns vs. html.icns: sure. This bug is currently owned by marlon@netscape.com. If the icon design is assumed by Simon Dorner, then this bug should be reassigned to him.
I would suggest using both a generic markup icon for xml files and a separate icon for (x)html files since they represent totally different things for the average user. I would further suggest to have an icon for css files. Of course I will create them if we can agree on this.
XML and (X)HTML aren't really categorically different, a web page could be any of the three. Users will get used to that. Leave the extension to distinguish between them. How about it, JJ? Do you want to stick with just two (mark-up and plain) text file types, or get into more detail, such as Mark-up (HTML, XHTML, XML) Style (CSS, XSL) Script (JS) and so on?
Hmmm, good point. css, xls, and js are currently not in the CFBundleDocumentTypes array. They should probably be added in the Info.plist, but we're drifting away from this bug's goal: create an icon family for Mozilla. In that respect, we should stick the families already identified. these 3 new types can definitely be included in the "text document" family for now. At least, they will inherit a Mozilla icon. Ultimately each extension / mime type should have its own CFBundleDocumentType defined but that's a lot of work and not a priority. I already count about 8 different icons, so let's get this first "minimum" set of icons done and we can think about extending it in the future. A separate bug could be filed for that (like "better distinguish document types in MacOS X Finder") as it doesn't necessarily affect icons design.
Take a look at http://www.theparallax.org/sd/proposals/mozilla/ - These are the final versions. Please give me some feedback.I will then take them and create scalable versions as described in the document.Thanks, Simon.
This will be fine for mozilla. We have a new icon style for the new toolkit apps, i'll be publishing docs on it soon.
S. Dorner, note that your old Mail icon would now be appropriate for the Minotaur/Thunderbird mail application.
Any luck with this, Simon? Do you think you'll make it in time for for 1.4b or 1.4?
The Icons are finally finished. Download them here: http://www.theparallax.org/sd/mozilla/ (Link should work soon) Please read the document for further discussion. Thanks, Simon.
Could someone please check the icons in? - I am not a developer. Guess it might be a little harder to get approval for checkin now, but the iconset shouldn't break anything and would be a great enhancement for 1.4. Download here: http://www.theparallax.org/sd/mozilla/mozilla-icons.tgz Please read the documentation mentioned above before checkin. Thanks a lot! Simon.
Setting blocking1.4?. It'd be nice if these could make it in.
Flags: blocking1.4?
I have changed the names of the icon files based on jj's suggestions to make them more descriptive. See bug 178742 for more info.
Who can check these in? I don't think marlon's gonna and I'm pretty sure JJ is on vacation. Kerz, can you land this stuff?
Not gonna hold 1.4 for this but we'd certainly consider taking the icons for 1.4 if someone has it all ready to go.
Flags: blocking1.4? → blocking1.4-
I think it should be no problem to have these in for 1.4. I just attached a patch for Info.plist to bug 178742 which provides filetype associations with all the icons from this set. I've requested review for that. Everything should work right away once these two are checked in. - Its just that someone has to do that...
Attached file Updated Info.plist (obsolete) —
I have posted a revised Info.plist in Bug 178742 over a week ago and nothing happened. Following a suggestion from Greg I now post it here. ---- From my post: ---- This introduces associations with the following file types: * Mozilla Preferences File * Mozilla Plugin * Mozilla Command Line File * Mozilla Shared Library * Mozilla Binary File It slightly updates or completes support for: * Text Document * HTML Document Support for image files remains unchanged - say "slightly broken" - as it still references a nonexistent icon file, albeit one with a more meaningful name. :) CFBundleIconFile has been changed from "mach" to "mozilla.icns" -------- I have further included all image file types that lib p0rn supports. The version string is now 1.4. It probably has to be changed. I hope this will now get the attention that is needed to finally fix this little bug.
Does anyone have time to baby this in?
I will do it. I see 3 steps: 1/ Make a patch showing the diffs for Info.plist and the appropriate Makefile.in 2/ Delete /mozilla/xpfe/bootstrap/macbuild/mach.icns 3/ Add all of the new .icns files to /mozilla/xpfe/bootstrap/macbuild/Contents/ Anything else?
Status: NEW → ASSIGNED
Attachment #124235 - Flags: superreview?(sfraser)
Attachment #124235 - Flags: review?(timeless)
Attachment #124235 - Flags: review?(timeless) → review+
Taking, since I made the patch. Is this going in or isn't it?
Assignee: marlon → lordpixel
Status: ASSIGNED → NEW
Has a patch, re-nominating for 1.4.
Flags: blocking1.4- → blocking1.4?
What is the chance of getting that patch its superreview (and maybe even getting it checked in)? I really doubt it is blocking 1.4 if it doesn't have a sr.
Blocks: 114202
Comment on attachment 124235 [details] [diff] [review] Incorporates changes to Info.plist, and Makefile.in changes required to deploy the new icns files >Index: Makefile.in >=================================================================== >RCS file: /cvsroot/mozilla/xpfe/bootstrap/Makefile.in,v >retrieving revision 1.236 >diff -u -2 -r1.236 Makefile.in >--- Makefile.in 18 Apr 2003 20:54:02 -0000 1.236 >+++ Makefile.in 26 May 2003 19:42:50 -0000 >@@ -430,5 +430,11 @@ > mkdir -p $(DIST)/$(APP_NAME).app/Contents/Plug-Ins > cp -R $(DIST)/package/PrintPDE.plugin $(DIST)/$(APP_NAME).app/Contents/Plug-Ins/ >- cp -RL $(srcdir)/macbuild/mach.icns $(DIST)/$(APP_NAME).app/Contents/Resources/mach.icns >+ cp -RL $(srcdir)/macbuild/Contents/command.icns $(DIST)/$(APP_NAME).app/Contents/Resources/command.icns >+ cp -RL $(srcdir)/macbuild/Contents/component.icns $(DIST)/$(APP_NAME).app/Contents/Resources/component.icns >+ cp -RL $(srcdir)/macbuild/Contents/html.icns $(DIST)/$(APP_NAME).app/Contents/Resources/html.icns >+ cp -RL $(srcdir)/macbuild/Contents/mozilla.icns $(DIST)/$(APP_NAME).app/Contents/Resources/mozilla.icns >+ cp -RL $(srcdir)/macbuild/Contents/plugin.icns $(DIST)/$(APP_NAME).app/Contents/Resources/plugin.icns >+ cp -RL $(srcdir)/macbuild/Contents/pref.icns $(DIST)/$(APP_NAME).app/Contents/Resources/pref.icns >+ cp -RL $(srcdir)/macbuild/Contents/text.icns $(DIST)/$(APP_NAME).app/Contents/Resources/text.icns > cp -RL $(DIST)/package/mozillaSuite.rsrc $(DIST)/$(APP_NAME).app/Contents/Resources/$(PROGRAM).rsrc > echo -n APPLMOZZ > $(DIST)/$(APP_NAME).app/Contents/PkgInfo cp -RL $(srcdir)/macbuild/Contents/*.icns?
Attachment #124235 - Flags: superreview?(sfraser) → superreview+
This is not going to block the release of 1.4. That's not to say it wouldn't be considered for inclusion in the release. To nominate a patch for landing on the 1.4 branch please use the patch flag "approval1.4?". Thanks.
Flags: blocking1.4? → blocking1.4-
Status: NEW → ASSIGNED
Checked into the trunk with smfr's suggested Makefile modification.
Don't want to be a pain in the a** but file icons: 129, 130, 138, 139 and 142 all have the capital "M" leaking on the right and bottom side of the icon. This surely wasn't intended?
What do you mean exactly? I'm looking at the icons from the latest build at 1600% magnification on a black background and I just don’t see it. Are you sure that you are looking at the newest version? - 129, 130, 138, 139 and 142 are the old filenames. I know that the M overlapped the Document Picture some time ago, but that's been fixed forever. However I can't remember actually releasing these versions. The newest icon set, and the one that’s apparently been checked in can be found here: http://www.theparallax.org/sd/mozilla/ The Pictures contained in the pages linked under "older versions" may contain all sorts of glitches. BTW: Thanks for checking in, lordpixel! Should this be nominated for inclusion in 1.4 as Asa Dotzler mentioned earlier?
Looking at nightly build 2003-06-11-08-trunk I see that all the icons are contained in Mozilla/Contents as well as Mozilla/Contents/Resources. Is this intended?
You are right Simon, I only checked the attachement. Final icons look perfect.
Simon, you're right. They shouldn't be copied into both places. I'll post a Makefile patch in a moment. I'll also have to remove *.icns from xpfe/bootstrap/macbuild/Contents/ and put them in xpfe/bootstrap/macbuild/Contents/Resources (which is probably where they should have been all along).
Comment on attachment 125470 [details] [diff] [review] Remove cp *.icns, because rsync command a few lines up will copy the icons, so long as I move them to the right place in CVS Approval for 1.4 is naturally for the 2 patches combined, so the icons only get copied once. I'll also have to edit Info.plist to ensure the version number remains 1.4 not 1.5
Attachment #125470 - Flags: superreview?(sfraser)
Attachment #125470 - Flags: review?(timeless)
Attachment #125470 - Flags: approval1.4?
Attachment #125470 - Flags: review?(timeless) → review+
Can I get some love on this one line Makefile change please?
Attachment #125470 - Flags: superreview?(sfraser) → superreview+
Checked Makefile.in fix into the trunk and moved the icons into the /mozilla/xpfe/bootstrap/macbuild/Contents/Resources/ directory in CVS. a= for branch? If we want to use the new icons with 1.4 Final it'll have to be soon...
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment on attachment 125470 [details] [diff] [review] Remove cp *.icns, because rsync command a few lines up will copy the icons, so long as I move them to the right place in CVS a=asa (on behalf of drivers) for checkin to the 1.4 branch.
Attachment #125470 - Flags: approval1.4? → approval1.4+
Keywords: fixed1.4
Now that this has gone in, I'm curious as to whether these could be used across the board? I know Win XP supports up to 64x64px icons, and I don't think there is any real limit on *nix. Would it be possible to standerdize on these icons? Any people on other platforms, would you be interested in these icons?
I agree that the all builds that can take the better icons should. (should be a separate bug though). These icons look *MUCH* better than the previous one. Even nicer design than the 1.2 icons for windows. Good job!!!!
Keywords: verifyme
QA Contact: sairuh → nobody
I was the person who created the blue 'M' icon currently in use. It was intended as a short term hack until I had time to design a proper icon suite, and I fully accept criticism of it. Since then I've offered to complete the job several times but no one has ever responded. If anyone needs the original artwork or would like me to help with a final icon suite please contact me. I'm more than happy to help with this issue.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: