Closed Bug 341926 Opened 19 years ago Closed 19 years ago

Cleanup in MainController.mm -validateMenuItem

Categories

(Camino Graveyard :: General, defect)

PowerPC
macOS
defect
Not set
trivial

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: froodian, Assigned: froodian)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 3 obsolete files)

The validateMenuItem code is inconsistent, and fails to follow the coding style guidelines (spaces vs. tabs, ![foo bar] vs [foo bar] == nil, no else after returns). Also, the viewSource selector has its own if statement, even though it could be placed under one of the group ifs. Patch forthcoming.
Severity: normal → trivial
Attached patch Patch (obsolete) — Splinter Review
This changes no behavior (hopefully) - It just cleans up.
Attachment #226053 - Flags: review?(stuart.morgan)
Blocks: 341853
Comment on attachment 226053 [details] [diff] [review] Patch One nit, >+ /* action == @selector(goHome:) || */ // always enabled >+ /* action == @selector(doSearch:) || */ // always enabled No need to leave these two lines in, the comment above the if adequately describes what we want to enable/disable, and its pretty clear these should be enabled even when the bookmark manager is visible. With that fixed r+ = me.
Attachment #226053 - Flags: review-
Attached patch r=bruced patch (obsolete) — Splinter Review
Assignee: nobody → stridey
Attachment #226053 - Attachment is obsolete: true
Status: UNCONFIRMED → ASSIGNED
Attachment #226187 - Flags: review?(nick.kreeger)
Attachment #226053 - Flags: review?(stuart.morgan)
Comment on attachment 226187 [details] [diff] [review] r=bruced patch second-r=me. Can we get this checked in ASAP, since Ian and I are about to tackle a huge pile of code in this area and we'd prefer this not bitrot? Requesting sr from pink. cl
Attachment #226187 - Flags: superreview?(mikepinkerton)
Attachment #226187 - Flags: review?(nick.kreeger)
Attachment #226187 - Flags: review+
Attached patch Unbitrots it (obsolete) — Splinter Review
> Can we get this checked in ASAP, since Ian and I are about to tackle a huge > pile of code in this area and we'd prefer this not bitrot? Too late. ;) This brings the patch up to date with the current tree. The above comment still applies. :)
Attachment #226187 - Attachment is obsolete: true
Attachment #226597 - Flags: superreview?(mikepinkerton)
Attachment #226187 - Flags: superreview?(mikepinkerton)
Comment on attachment 226597 [details] [diff] [review] Unbitrots it sr=pink
Attachment #226597 - Flags: superreview?(mikepinkerton) → superreview+
Whiteboard: [needs checkin]
// check what the state of the personal toolbar should be, but only if there is a browser // window open. Popup windows that have the personal toolbar removed should always gray // out this menu. if (action == @selector(toggleBookmarksToolbar:)) { if (browserController) { NSView* bookmarkToolbar = [browserController bookmarkToolbar]; if ( bookmarkToolbar ) { float height = [bookmarkToolbar frame].size.height; BOOL toolbarShowing = (height > 0); if (toolbarShowing) [mBookmarksToolbarMenuItem setTitle: NSLocalizedString(@"Hide Bookmarks Toolbar",@"")]; else [mBookmarksToolbarMenuItem setTitle: NSLocalizedString(@"Show Bookmarks Toolbar",@"")]; return YES; } - else - return NO; - } - else return NO; + } + return NO; } Why is there a need for these two return NO calls?
Assignee: stridey → nobody
Status: ASSIGNED → UNCONFIRMED
// check what the state of the personal toolbar should be, but only if there is a browser // window open. Popup windows that have the personal toolbar removed should always gray // out this menu. if (action == @selector(toggleBookmarksToolbar:)) { if (browserController) { NSView* bookmarkToolbar = [browserController bookmarkToolbar]; if ( bookmarkToolbar ) { float height = [bookmarkToolbar frame].size.height; BOOL toolbarShowing = (height > 0); if (toolbarShowing) [mBookmarksToolbarMenuItem setTitle: NSLocalizedString(@"Hide Bookmarks Toolbar",@"")]; else [mBookmarksToolbarMenuItem setTitle: NSLocalizedString(@"Show Bookmarks Toolbar",@"")]; return YES; } - else - return NO; - } - else return NO; + } + return NO; } Why is there a need for these two return NO calls?
Assignee: nobody → stridey
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attached patch Even BetterSplinter Review
Gets rid of the extra Return NO
Attachment #226597 - Attachment is obsolete: true
Fixed trunk and branch
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: