Live resize of tabs as the window resizes....

Live resize of tabs as the window resizes.
BUG=13713
TEST=dragging tabs still animates, new tabs still animate, resizing window live-resizes tabs.

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

[viettrungluu-gmail, 2009-07-24 16:04:46]

LGTM. Good catch on my missing removeObserver, and your method names are more
Obj-C/Cocoa-ish. :-) Only question: The calls to [NSAnimationContext
beginContext/endContext/etc.] should be pretty low-cost, right?

[pink (ping after 24hrs), 2009-07-24 16:08:00]

I think they should be low-cost in the non-animation case. I thought
about wrapping them in if()s but thought it might make the code too
hard to follow.

On Fri, Jul 24, 2009 at 12:04 PM, <viettrungluu@gmail.com> wrote:
> LGTM. Good catch on my missing removeObserver, and your method names are
> more Obj-C/Cocoa-ish. :-) Only question: The calls to
> [NSAnimationContext beginContext/endContext/etc.] should be pretty
> low-cost, right?
>
> http://codereview.chromium.org/159346
>



-- 
Mike Pinkerton
Mac Weenie
pinkerton@google.com

[viettrungluu-gmail, 2009-07-24 16:09:49]

On 2009/07/24 16:08:00, pink wrote:
> I think they should be low-cost in the non-animation case. I thought
> about wrapping them in if()s but thought it might make the code too
> hard to follow.

Okay, I agree. LG.

[rohitrao (ping after 24h), 2009-07-24 16:11:22]

lgtm

http://codereview.chromium.org/159346/diff/6/1008
File chrome/browser/cocoa/tab_strip_controller.mm (right):

http://codereview.chromium.org/159346/diff/6/1008#newcode261
Line 261: // Move the current tab to the correct location intantly.
Typo: intantly.

[TVL, 2009-07-24 16:27:02]

lgtm

http://codereview.chromium.org/159346/diff/6/1008
File chrome/browser/cocoa/tab_strip_controller.mm (right):

http://codereview.chromium.org/159346/diff/6/1008#newcode299
Line 299: id frameTarget = visible && animate ? [[tab view] animator] : [tab
view];
line 268 this was "target", here it's "frameTarget", any reason for different
naming of the same thing?

[TVL, 2009-07-24 16:29:16]

What about making a C++ stackbased class that wrapped this?  Have it take a bool
in the ctor to disable it, and it's get() can return nil when it's disabled so
the obj methods noop out?  then the code reads, and it could end the group when
it goes out of scope?  Seems like we might need this for other things when we
put animations back in?

TVL

On 2009/07/24 16:08:00, pink wrote:
> I think they should be low-cost in the non-animation case. I thought
> about wrapping them in if()s but thought it might make the code too
> hard to follow.
> 
> On Fri, Jul 24, 2009 at 12:04 PM, <viettrungluu@gmail.com> wrote:
> > LGTM. Good catch on my missing removeObserver, and your method names are
> > more Obj-C/Cocoa-ish. :-) Only question: The calls to
> > [NSAnimationContext beginContext/endContext/etc.] should be pretty
> > low-cost, right?
> >
> > http://codereview.chromium.org/159346
> >
> 
> 
> 
> -- 
> Mike Pinkerton
> Mac Weenie
> pinkerton@google.com