[Mac] M6 Omnibox positioning changes.

[Mac] M6 Omnibox positioning changes.

3px from top and bottom of images to cell edges in popup.  With this
change baselines worked out without tweaking.

Omnibox popup text wasn't quite aligned with field because previous
change used leading 'w' (regression).  This change measured using
leading 'P'.

Adjust keyword-hint decoration spacing around the image.  Also adjust
baseline to match font (regression).

Modify ImageDecoration to center the image horizontally, which allows
the decoration width to be independent of the image width.
PageActionDecoration uses this to pin the effective size at
|kPageActionIconMaxSize|.

Position page-action and bookmark popups so top border is at same gap
from Omnibox (2px) as Omnibox popup.  The mocks actually show the
bookmark point as an additional px from the star "crotch", but I think
this is reasonable for M6.

BUG=50575, 50765
TEST=none.  Everything still works?

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=54767

[Scott Hess - ex-Googler, 2010-08-02 23:09:55]

Rohit, to you since you're probably most familiar with the context.  Either stop
by or ask Andy if you want to inspect the specific mocks.

[rohitrao (ping after 24h), 2010-08-02 23:44:57]

Mostly this is a bunch of constants changing from one magic value to another. 
I'm assuming the new values are better :)

I had a few other questions.

http://codereview.chromium.org/3015046/diff/1/4
File chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm (right):

http://codereview.chromium.org/3015046/diff/1/4#newcode107
chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm:107:
std::floor([hint_prefix_ sizeWithAttributes:attributes_].width + 0.5) +
Why are you adding 0.5 and flooring?  Is that just to round to the nearest
integer?  Can you add a comment?

http://codereview.chromium.org/3015046/diff/1/4#newcode124
chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm:124: const CGFloat
prefix_width =
This logic has changed.  Are you intentionally not setting prefix_rect.width
anymore?

http://codereview.chromium.org/3015046/diff/1/4#newcode147
chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm:147: const CGFloat
suffix_width =
Same question here.

http://codereview.chromium.org/3015046/diff/1/6
File chrome/browser/cocoa/location_bar/page_action_decoration.mm (right):

http://codereview.chromium.org/3015046/diff/1/6#newcode195
chrome/browser/cocoa/location_bar/page_action_decoration.mm:195: NSPoint
PageActionDecoration::GetBubblePointInFrame(NSRect frame) {
This logic is here so that different icons with different heights still position
the bubble at the same y-coordinate?  If so, can you add the "at the same
y-coordinate" explanation to the comment somewhere?

[Scott Hess - ex-Googler, 2010-08-03 04:47:02]

On 2010/08/02 23:44:57, rohitrao wrote:
> Mostly this is a bunch of constants changing from one magic value to another. 
> I'm assuming the new values are better :)

New values are "better" where the optimization function is "more similar to
mocks".  Actually the keyword-hint change is materially better, previously I
wasn't very happy with the spacing of that.

http://codereview.chromium.org/3015046/diff/1/4
File chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm (right):

http://codereview.chromium.org/3015046/diff/1/4#newcode107
chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm:107:
std::floor([hint_prefix_ sizeWithAttributes:attributes_].width + 0.5) +
On 2010/08/02 23:44:58, rohitrao wrote:
> Why are you adding 0.5 and flooring?  Is that just to round to the nearest
> integer?  Can you add a comment?

Added a comment.  Basically, any partial pixel could be mostly covered, or
slightly covered, so the goal is not to have the visual weight be too tight or
loose.

http://codereview.chromium.org/3015046/diff/1/4#newcode124
chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm:124: const CGFloat
prefix_width =
On 2010/08/02 23:44:58, rohitrao wrote:
> This logic has changed.  Are you intentionally not setting prefix_rect.width
> anymore?

The width didn't matter so long as it was longer than needed.  The rect should
automatically be that way (due to the width calculation), so rather than explain
why it was drawing to one width and adding a different width below, I just
removed the unnecessary setting.

http://codereview.chromium.org/3015046/diff/1/4#newcode147
chrome/browser/cocoa/location_bar/keyword_hint_decoration.mm:147: const CGFloat
suffix_width =
On 2010/08/02 23:44:58, rohitrao wrote:
> Same question here.

Again, there should be more than enough width left.  Hmm.  I'll add DCHECK_GE()
to assert this.

http://codereview.chromium.org/3015046/diff/1/6
File chrome/browser/cocoa/location_bar/page_action_decoration.mm (right):

http://codereview.chromium.org/3015046/diff/1/6#newcode195
chrome/browser/cocoa/location_bar/page_action_decoration.mm:195: NSPoint
PageActionDecoration::GetBubblePointInFrame(NSRect frame) {
On 2010/08/02 23:44:58, rohitrao wrote:
> This logic is here so that different icons with different heights still
position
> the bubble at the same y-coordinate?  If so, can you add the "at the same
> y-coordinate" explanation to the comment somewhere?

Done.  I think.

[rohitrao (ping after 24h), 2010-08-03 16:07:52]

LGTM