Closed
Bug 488861
Opened 15 years ago
Closed 15 years ago
Add a CFBundleDisplayName to crash_report_sender.app
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: alqahira, Assigned: alqahira)
References
Details
Attachments
(2 files, 1 obsolete file)
13.09 KB,
patch
|
stuart.morgan+bugzilla
:
superreview+
|
Details | Diff | Splinter Review |
9.67 KB,
patch
|
Details | Diff | Splinter Review |
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.
Assignee | ||
Comment 1•15 years ago
|
||
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)
Assignee | ||
Comment 2•15 years ago
|
||
Er, one after finally: do we want to make it be "Camino Crash Reporter" or is "Crash Reporter" OK?
Status: NEW → ASSIGNED
Comment 3•15 years ago
|
||
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
Assignee | ||
Comment 4•15 years ago
|
||
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)
Updated•15 years ago
|
Attachment #373546 -
Attachment is obsolete: true
Comment 5•15 years ago
|
||
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).
Assignee | ||
Comment 6•15 years ago
|
||
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)
Updated•15 years ago
|
Attachment #374719 -
Flags: superreview?(stuart.morgan+bugzilla) → superreview+
Comment 7•15 years ago
|
||
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.
Assignee | ||
Comment 8•15 years ago
|
||
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
Assignee | ||
Comment 9•15 years ago
|
||
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.
Description
•