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)

PowerPC
macOS
enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: hsivonen, Assigned: lordpixel)

References

Details

(Keywords: fixed1.4, verifyme)

Attachments

(2 files, 3 obsolete files)

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