399346 - Decide on .tiff or .tif

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[Mark Mentovai]

We currently have some TIFF images with a .tiff extension, and some with a .tif extension.  We should standardize on one.  I prefer .tiff, but we've currently got more .tif files: on the trunk, there are now 24 .tiff files and 85 .tif files.

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I prefer .tiff, too.

Comment 2

[Wevah (Nate Weaver)]

I also prefer .tiff. I think .tif is prevalent only because Photoshop (at least older versions) insists on defaulting to three-letter extensions.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

When we do this--or some other renaming exercise--we should consider fixing historyicon.tif's name.  It should really be named history_icon.tif[f] to be in sync with the other Bookmarks Manager collection icons.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Also fun, apparently the Downloads window toolbar icons are all specified in code with explicit "foo.tif" names, whereas in most of the rest of Camino, we just use the file's name.

Some of the main toolbar's images are also specified in such a manner (add_to_bookmark.tif, textBigger.tif, textSmaller.tif, newTab.tif, closeTab.tif, sendLink.tif, dl_manager.tif), so we'll have to fix them, too, when we do this.

Comment 5

[Mark Mentovai]

We can do a patch to get the ".tif" (and ".tiff", if any) names out of string literals before or at the same time as the renaming.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

What about ones referenced in nibs?  Are they being referenced with the full filename (and how would one go about finding this out)?

Comment 7

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Remove mentions of explicit extensions in code [checked in]

This patch removes all the explicit mentions of filename extensions in code (coincidentally, they're all .tif).

The only other places that extensions are mentioned are the project file or the Info-FooPrefPane.plist files (do those latter need to be changed, too?).

Comment 8

[Mark Mentovai]

Comment on attachment 295557 [details] [diff] [review]
Remove mentions of explicit extensions in code [checked in]

Leave the Info.plists alone.  The system only looks for icons by appending the .icns extension.  We can convert these to .icns files but they'll be a little larger.  I do recall that TIFFs weren't always supported as CFBundleIconFiles, so you might want to check to see if the "get info" icons are correct on 10.3 and 10.4.

A grep for '\.tif' on the nibs should show you any occurrences of that string, even in binary files (you'll see "binary file keyedobjects.nib matches").  For true paranoia, convert the keyedobjects.nib files to xml1 before grepping:

find mozilla/camino -name keyedobjects.nib -exec plutil -convert xml1 {} \;
grep '\.tif' `find mozilla/camino -type f -name \*.nib`

This'll grep you through sparkle too, which you probably don't want, so you might want to be more restrictive and only look in resources and PreferencePanes.

I'd advise not using nibs once you've run them through plutil, so it might be best to do this experiment in a tree that you don't care about - maybe make a copy and work in there.

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 295557 [details] [diff] [review]
Remove mentions of explicit extensions in code [checked in]

Landed these code changes on the trunk and MOZILLA_1_8_BRANCH.

Comment 10

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: full trunk patch (includes dom_json.xpt from bug 412126)

I thought this would be a quiet weekend to finish this up, with no outstanding project patches to bitrot.  Then bug 412126 came along.  So, I'll bitrot myself.  Or, maybe not.

This is the full cvs diff of the project, MainController and BookmarkManager (for the history_icon renaming, comment 3), and the removed and added images.  The project diff includes the dom_json.xpt change from bug 412126.  For reference, I'll also attach a trunk-project-only diff that shows the diff against the project with dom_json.xpt already in it.

And, for your further reviewing fun, I'll also attach a branch project diff, since that part obviously won't cross-commit.

In both cases, I've cleaned and then rebuilt and verified that everything I could think to open that had images in it still had the images.

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: trunk project patch without the json stuff being +/-ed

Maybe this isn't the most useful alternative diff?

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: branch project patch

Here's the branch project all by itself, since it's the only part of the full trunk patch that won't cross-commit.

Comment 13

[Mark Mentovai]

Comment on attachment 296783 [details] [diff] [review]
full trunk patch (includes dom_json.xpt from bug 412126)

I trust that the new files were added with -kb.

Comment 14

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #13)
> (From update of attachment 296783 [details] [diff] [review])
> I trust that the new files were added with -kb.

Your trust is not misplaced.

Camino has spoken; the decision is in: it's .tiff.

Checked in on the trunk and MOZILLA_1_8_BRANCH in advance of Camino 1.6b1.  I do hope this is the first and only time in my life I will do a 24-minute commit.  

So far, it looks like the timing went well as to produce no red boxen.