Closed Bug 488861 Opened 15 years ago Closed 15 years ago

Add a CFBundleDisplayName to crash_report_sender.app

Categories

(Camino Graveyard :: General, defect)

All
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: alqahira, Assigned: alqahira)

References

Details

Attachments

(2 files, 1 obsolete file)

crash_report_sender currently reports its name in the Dock, the menubar, and the Hide/About menus as "crash_report_sender".  That's ugly :P

We should supply our own CFBundleDisplayName and friends (i.e., implement bug 382762 here).  My plan right now is to try to do this via a shell script build phase so that our changes won't get stomped by Breakpad updates.
This is a bit of a hack, but it's an effective hack, and without Google providing cleaner integration points, this is more-or-less the best we can do.

I (ab)use defaults to add the missing keys to crash_report_sender.app's Info.plist (note that the dire warning about the general manipulation moving to another tool has been there since at least 10.3), and then I printf+iconv what will become English.lproj/InfoPlist.strings.

The script is keyed to execute as early as possible in the build mostly for developer convenience (i.e., help LaunchServices out by not modifying the copy we'll eventually be running, but it's still possible the Finder filename may not visibly update, though the Dock and menu will be fine).  

The script should run any time the Breakpad.framework is newer than either of the files we need to change; since xcodebuild is nice enough to touch the framework right after its build phase, this will cause us to always regenerate these files.  If you can think of a better way to ensure we always update when needed but not update on every build, I'd be glad to use it.

Finally, I don't know what our policy on paths vs. variables is; should I redefine the output file paths using the input file variable and then change the script to use the output file variables instead of the paths?
Attachment #373546 - Flags: superreview?(stuart.morgan+bugzilla)
Er, one after finally: do we want to make it be "Camino Crash Reporter" or is "Crash Reporter" OK?
Status: NEW → ASSIGNED
I think we probably want "Camino Crash Reporter".

Given the hackishness of having to stuff things into the Info.plist, and the likelyhood that others would also not want crash_report_sender as a visible name, I'm going to try to upstream a basic localization so all we have to do is replace the .strings file:
http://code.google.com/p/google-breakpad/issues/detail?id=313
Comment on attachment 373546 [details] [diff] [review]
Banish crash_report_sender in visible UI

Clearing this from Stuart's queue while we await upstream changes.

I'm in favor of fewer hacks and better built-in integration points :)
Attachment #373546 - Flags: superreview?(stuart.morgan+bugzilla)
Attachment #373546 - Attachment is obsolete: true
Comment on attachment 373546 [details] [diff] [review]
Banish crash_report_sender in visible UI

I bumped us to r330, which has my upstream change based on your patch here. Now all we need is a replacement InfoPlist.strings, so it may be easiest to just land our version somewhere in our tree and then use a copy phase to drop it in place (assuming Xcode won't do the wrong thing based on timestamps; if it does we could make a shell script phase that does a copy).
Here's a patch that uses a copy phase.  I'm not really in love with it (I'd rather avoid landing something we control as -kb), but it works and is probably simpler than a shell script phase.

I'm not sure the best place for the file to live, but I stuffed it in a "camino" folder inside "google-breakpad", and in the project it lives in a folder inside "Resources".
Attachment #374719 - Flags: superreview?(stuart.morgan+bugzilla)
Attachment #374719 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
Comment on attachment 374719 [details] [diff] [review]
Alternate approach

sr=smorgan, but I think I'd rather we land the file in resources/google-breakpad, rather than putting it in the google-breakpad folder. Right now that's clean except for our README, and I'd prefer we keep it that way.

Also, should we maybe use $(BUILT_PRODUCTS_DIR)/$(FRAMEWORKS_FOLDER_PATH)/Breakpad.framework/... for the destination? We only really care about changing the bundled copy. I'm fine either way on that though.
Checked in with both of Stuart's comments addressed (and the copy phase moved after the "Copy Frameworks" phase, of course); amazingly, LS seemed happy enough :P
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
cb-miniosx01 and cb-minibinus01 both went red first cycle after landing the initial patch (unify complained the files weren't identical, and in fact the copy phase didn't run in the Intel build) but later went green.

Stuart diagnosed this as a timestamp problem, and we switched to using a shell script phase (this patch).  So far we haven't seen a repeat of this red; fingers crossed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: