Open Bug 664309 Opened 8 years ago Updated 7 years ago

Make the built-in ChatZilla display a cZ icon in SeaMonkey

Categories

(SeaMonkey :: Build Config, defect, trivial)

defect
Not set
trivial

Tracking

(Not tracked)

People

(Reporter: tonymec, Unassigned)

References

Details

(Keywords: helpwanted)

Attachments

(1 file)

This is a followup to bug 645627; our purpose here is to get a distinctive cZ taskbar-and-window-corner icon for ChatZilla-in-SeaMonkey even though the current packaging procedure forces an install as a packed xpi. I'll be ASSIGNing it to myself _because_ I believe that it is a "good first bug": if I succeed it will be my first change in the code of any one of the major Mozilla applications (in this case, SeaMonkey), so I suppose I shall need guidance. Also, please bear with me: no patch yet, I'm still at the design stage.

I see several possibilities:

1. "one-time copy" solution: copy the already existing cZ icon (in all its platform-dependent variants) once and for all ("at bug-fixing time") into some "SeaMonkey" directory (so that it makes its way into <appdir>/chrome/icons/default/ IIUC), make sure that the cZ window gets that at runtime instead of the "generic" Sm icon (which it gets now), and have done with it.
- Advantage: I expect it's the easiest solution.
- Disadvantage: If the ChatZilla owners decide that they want a new logo, it won't be picked automagically.
- My opinion: IMHO this is easiest but ugliest; I don't like it.

2. "conditional push" solution: inside some ChatZilla makefile, add the necessary lines to do the above-mentioned copy whenever ChatZilla is built *as part of SeaMonkey*. This will require either a makefile if(n)def or a bash-script if.

3. "packaging pull" solution: modify only comm-central files, and in such way that when building-and-packaging SeaMonkey the icons are pulled from the ChatZilla hg repository and become "part of SeaMonkey".

Of the latter two, I prefer #3 because I regard it as more elegant. IIUC #2 requires writing some ../../something paths which concern SeaMonkey far down inside the ChatZilla repository, and I can very well imagine that if in, say, five years, the architecture of the comm-central repository is redesigned, no one will remember that there is a makefile down in ChatZilla which needs a change (maybe even not me: I'm 60 years old now, I may be a doddering old fool by then, if not six feet under ;-) ). OTOH, I can just imagine (but maybe I'm too optimistic) that it will be possible to define the icons (in the "SeaMonkey" location mentioned under 1 above) as symlinks to the ChatZilla icons in @TOPSRCDIR@/mozilla/extensions/irc/whatever so that the "make package" step will pick them up (resolving the symlink) so that the current cZ logo and any future "new cZ logo" will be picked up automagically without even the need to add new explicit copy instructions (I know, I'm dreaming, but now I think you can see why this is the variant I prefer).
Assignee: nobody → antoine.mechelynck
Status: NEW → ASSIGNED
Of those 3 solutions, I am ok with number 1 (since the icons change so infrequently) or number 3.

Number 3 would be a "pull..." from local repo only (in this case mozilla/extensions/irc/...  and done from some SeaMonkey Makefile/packaging

I'm not a fan of modifying the cZ source to accommodate this edge case, since cZ already unpacks for normal (at least AMO) installs.
Well, I'll fall back on #1 if I can't find how to get #3 to work then.

So let's start trying to find and understand the relevant Mozilla code bits then.

I've found that at suite/app/Makefile.in line 284, in target pack-ext, the built-in extensions, which are already together in unpacked form in (IIUC) <objdir>/mozilla/dist/bin/extensions/, are packed to xpi form into distribution/extensions/; but for the love of me I can't find where <objdir>/mozilla/dist/bin/extensions/{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}/ and its contents are built.

I suppose it might be OK to add a line before or after suite/app/Makefile.in line 264 (the line starting with "$(ZIP)" without the quotes) to copy the icons (if there are any) from any extension's chrome/icons/default/ directory to <objdir>/mozilla/dist/seamonkey/chrome/icons/default/ (with the proper $(something) to replace parts of these paths, and I haven't yet figured them all) -- what do you think? An added benefit would be that if, say, the Venkman devs ever want a different logo, or if we (SeaMonkey) want a distinctive debugQA logo, all that would be picked up automagically.
(In reply to comment #2)
> I suppose it might be OK to add a line before or after suite/app/Makefile.in
> line 264 (the line starting with "$(ZIP)" without the quotes) to copy the
> icons (if there are any) from any extension's chrome/icons/default/
> directory to <objdir>/mozilla/dist/seamonkey/chrome/icons/default/

No, please don't do "any", do the ChatZilla ones explicitely. We already do something like that for venkman, we just should follow along the same path for ChatZilla for now.
(In reply to comment #3)
> (In reply to comment #2)
> > I suppose it might be OK to add a line before or after suite/app/Makefile.in
> > line 264 (the line starting with "$(ZIP)" without the quotes) to copy the
> > icons (if there are any) from any extension's chrome/icons/default/
> > directory to <objdir>/mozilla/dist/seamonkey/chrome/icons/default/
> 
> No, please don't do "any", do the ChatZilla ones explicitely. We already do
> something like that for venkman, we just should follow along the same path
> for ChatZilla for now.

Well, where do we do it for Venkman and where would be the corresponding (symmetric / homologous) place for ChatZilla? Line 264 of suite/app/Makefile.in is inside a "for" loop over all 4 built-in extensions. Adding cZ just outside the loop would be special-casing one extension, while Venkman is handled somewhere else and (AFAIK) DOMi and DebugQA are not handled at all. Adding a test -d and a cp *.xpm *.ico (with a make-style leading dash to ignore errors) seemed to me to be an elegant solution. I will settle for a solution homologous to what we're already doing for Venkman. But I don't like the idea of special-casing Venkman one way in one Makefile and special-casing ChatZilla another way in another non-homologous Makefile.
We should handle ChatZilla and venkman the same way (debugQA doesn't have or need icons, DOMi might not have one, at least not a SeaMonkey-specific one).
Looking up how it's done for venkman (not sure about that right now) and following that should help.
There are already files named
suite/branding/nightly/icons/gtk/chatzilla-window.xpm
suite/branding/nightly/icons/os2/chatzilla-window.ico
suite/branding/nightly/icons/windows/chatzilla-window.ico
(nothing specifically for Mac)
but these seem to be old Suite icons (square divided diagonally, the topleft half dark bluish-grey with a white lowercase m, with a winking smiley, what's the English expression? atop the field? French heraldry "brochant sur le tout"), not what we want (and what our users have come to be accustomed to), which would be a simple greyish "cZ" logo.

These files were last modified in April 2010 by changeset 1331ca255dd4 (bug 525869 comment #13, IIUC attachment 435602 [details] [diff] [review], KaiRo, r=Standard8).

My linux64 SeaMonkey can show the Windows and GTK icons as file:/// URLs from my comm-central clone, but says the OS2 icons cannot be displayed "because the file has an error". My guess is the OS2 .ico format differs from that of Windows and is not understood by a non-OS2 Gecko.
(In reply to comment #6)
> There are already files named
> suite/branding/nightly/icons/gtk/chatzilla-window.xpm
> suite/branding/nightly/icons/os2/chatzilla-window.ico
> suite/branding/nightly/icons/windows/chatzilla-window.ico
> (nothing specifically for Mac)
> but these seem to be old Suite icons

1) Mac doesn't have window icons at all, so nothing wanted/needed there.
2) I guess new icons have never been done, and we failed to kill the old ones.
3) The given changset only moved stuff around.

> My linux64 SeaMonkey can show the Windows and GTK icons as file:/// URLs
> from my comm-central clone, but says the OS2 icons cannot be displayed
> "because the file has an error". My guess is the OS2 .ico format differs
> from that of Windows and is not understood by a non-OS2 Gecko.

Yes, OS/2 has a different .ico format than everyone else.
Well, time to confess: I'm lost. The source tree is too much of a maze for me. I don't think anymore that I'll be able to do it. I give up. This bug is up for grabs.
Assignee: antoine.mechelynck → nobody
Status: ASSIGNED → NEW
Whiteboard: [good first bug]
Workaround (not a fix):
1. With the latest SeaMonkey running, browse to about:addons (or use the "Tools → Add-ons Manager" menu or the Ctrl+Shift+A hotkey).
2. In the drop-down left of the search bar above the list of extensions, select "Install Add-on From File…"
3. In the file picker, browse to the seamonkey directory created by installing SeaMonkey, then to distribution/extensions/ (exact paths may vary somewhat depending on OS version and on whether SeaMonkey came from Mozilla or packaged with the OS)
4. Click on {59c81df5-4b7a-477b-912d-4e0fdf64e5f2}.xpi
5. The popup should say that you're about to install ChatZilla. After the countdown elapses, click "Install Now"
6. Once the doorhanger tells you that ChatZilla is installed, restart SeaMonkey.

This will install the built-in ChatZilla in your profile using the same routines as if it were "anywhere on your HD", and thus in "unpacked" mode, so that its cZ icon will appear on the taskbar and/or at the topleft window corner.
Whiteboard: [workaround see comment #10]
Venkman is a bad comparison since it's never shipped its own icon.

By comparison, DOM Inspector's icon doesn't seem to work at all...
(In reply to Phoenix from comment #12)
> Possibly helpful link for Windows -
> http://blogs.msdn.com/b/oldnewthing/archive/2012/08/20/10341464.aspx

Looks interesting — for Windows; but AFAICT not portable.
Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1 ID:20121019003003 c-c:bd22a204044b m-c:0ff60bfb3442

The workaround of comment #10 doesn't work anymore.
Whiteboard: [workaround see comment #10]
You need to log in before you can comment on or make changes to this bug.