[Mac] More progress towards resizing the Browser Actions container....

[Mac] More progress towards resizing the Browser Actions container.
o Icons fade out as they are moved off screen by resizing the window.
o Dragging the resizer actually resizes the container.
o Known issues include:
  + no chevron.
  + no updating of other windows if the size of the container changes.
  + the cursor is a bit wonky in updating its state.
o Fixes a slew of janky UI bugs relating to having a lot of extensions installed.

BUG=26990, 29838, 32101
TEST=none

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

[pink (ping after 24hrs), 2010-02-24 01:32:05]

no major problems, lots of little things.

http://codereview.chromium.org/657038/diff/1/2
File chrome/browser/cocoa/extensions/browser_actions_container_view.h (right):

http://codereview.chromium.org/657038/diff/1/2#newcode11
chrome/browser/cocoa/extensions/browser_actions_container_view.h:11: @interface
BrowserActionsContainerView : NSView {
Needs a class-level comment. Describe in what circumstances the notification
above is sent.

http://codereview.chromium.org/657038/diff/1/2#newcode12
chrome/browser/cocoa/extensions/browser_actions_container_view.h:12: // The
frame encompasing the grippy used for resizing the container.
@private

http://codereview.chromium.org/657038/diff/1/2#newcode50
chrome/browser/cocoa/extensions/browser_actions_container_view.h:50:
@property(nonatomic) BOOL canDragLeft;
should these be readonly?

http://codereview.chromium.org/657038/diff/1/3
File chrome/browser/cocoa/extensions/browser_actions_container_view.mm (right):

http://codereview.chromium.org/657038/diff/1/3#newcode50
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:50:
NSGradient* borderGradient = [[[NSGradient alloc]
use scoped_nsobject

http://codereview.chromium.org/657038/diff/1/3#newcode62
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:62: -
(void)drawGrippy {
Needs a method-level comment

http://codereview.chromium.org/657038/diff/1/3#newcode83
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:83: -
(void)resizeToWidth:(CGFloat)width animate:(BOOL)animate {
do you want to validate the width at all? ensure or assert that it's less than
some upper bound just to be safe?

http://codereview.chromium.org/657038/diff/1/3#newcode105
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:105: -
(NSCursor*)appropriateCursor {
needs comment

http://codereview.chromium.org/657038/diff/1/3#newcode120
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:120: -
(void)mouseDown:(NSEvent*)theEvent {
probably needs a comment describing how the drag loop works

http://codereview.chromium.org/657038/diff/1/3#newcode130
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:130: //
toolbar. Investigate further.
file a bug and include the bug# here.

http://codereview.chromium.org/657038/diff/1/4
File chrome/browser/cocoa/extensions/browser_actions_controller.h (right):

http://codereview.chromium.org/657038/diff/1/4#newcode25
chrome/browser/cocoa/extensions/browser_actions_controller.h:25: @interface
BrowserActionsController : NSObject {
Needs a class-level comment.

http://codereview.chromium.org/657038/diff/1/4#newcode76
chrome/browser/cocoa/extensions/browser_actions_controller.h:76: // Registers
the user preferences used by this class. Static.
"static" is implied by the "+", and static isn't used by obj-c for this purpose,
so it's an inappropriate description.

http://codereview.chromium.org/657038/diff/1/5
File chrome/browser/cocoa/extensions/browser_actions_controller.mm (right):

http://codereview.chromium.org/657038/diff/1/5#newcode78
chrome/browser/cocoa/extensions/browser_actions_controller.mm:78: [owner_
resizeContainerWithAnimation:NO];
don't you want animation in these cases? Wouldn't it be kinda cool?

http://codereview.chromium.org/657038/diff/1/5#newcode108
chrome/browser/cocoa/extensions/browser_actions_controller.mm:108: if
(!profile_->GetPrefs()->FindPreference(
i don't think we lazily register prefs anywhere else, is this done lazily on
windows too?

http://codereview.chromium.org/657038/diff/1/5#newcode172
chrome/browser/cocoa/extensions/browser_actions_controller.mm:172: if
(predefinedWidth != 0)
is it worth verifying it's > 0?

http://codereview.chromium.org/657038/diff/1/5#newcode248
chrome/browser/cocoa/extensions/browser_actions_controller.mm:248: -
(void)resizeContainerWithAnimation:(BOOL)animate {
needs comment

http://codereview.chromium.org/657038/diff/1/5#newcode259
chrome/browser/cocoa/extensions/browser_actions_controller.mm:259: -
(void)containerFrameChanged {
needs comment

http://codereview.chromium.org/657038/diff/1/5#newcode284
chrome/browser/cocoa/extensions/browser_actions_controller.mm:284: -
(void)containerDragFinished {
needs comment

http://codereview.chromium.org/657038/diff/1/5#newcode299
chrome/browser/cocoa/extensions/browser_actions_controller.mm:299: -
(void)updateDragAbilities {
needs comment

http://codereview.chromium.org/657038/diff/1/6
File chrome/browser/cocoa/toolbar_controller.mm (right):

http://codereview.chromium.org/657038/diff/1/6#newcode607
chrome/browser/cocoa/toolbar_controller.mm:607: if
(![[browserActionsContainerView_ window] isVisible])
what if the window is minimized or the app is hidden? will that cause things to
be out of sync when the window is brought back to view?

[Bons, 2010-02-24 21:03:53]

Thanks for initial feedback. No need for another pass until I've implemented it
more completely.

http://codereview.chromium.org/657038/diff/1/2
File chrome/browser/cocoa/extensions/browser_actions_container_view.h (right):

http://codereview.chromium.org/657038/diff/1/2#newcode11
chrome/browser/cocoa/extensions/browser_actions_container_view.h:11: @interface
BrowserActionsContainerView : NSView {
On 2010/02/24 01:32:05, pink wrote:
> Needs a class-level comment. Describe in what circumstances the notification
> above is sent.

Done.

http://codereview.chromium.org/657038/diff/1/2#newcode12
chrome/browser/cocoa/extensions/browser_actions_container_view.h:12: // The
frame encompasing the grippy used for resizing the container.
On 2010/02/24 01:32:05, pink wrote:
> @private

Done.

http://codereview.chromium.org/657038/diff/1/2#newcode50
chrome/browser/cocoa/extensions/browser_actions_container_view.h:50:
@property(nonatomic) BOOL canDragLeft;
On 2010/02/24 01:32:05, pink wrote:
> should these be readonly?

Only isResizing. Done.

http://codereview.chromium.org/657038/diff/1/3
File chrome/browser/cocoa/extensions/browser_actions_container_view.mm (right):

http://codereview.chromium.org/657038/diff/1/3#newcode50
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:50:
NSGradient* borderGradient = [[[NSGradient alloc]
On 2010/02/24 01:32:05, pink wrote:
> use scoped_nsobject

Done.

http://codereview.chromium.org/657038/diff/1/3#newcode62
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:62: -
(void)drawGrippy {
On 2010/02/24 01:32:05, pink wrote:
> Needs a method-level comment

Done.

http://codereview.chromium.org/657038/diff/1/3#newcode83
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:83: -
(void)resizeToWidth:(CGFloat)width animate:(BOOL)animate {
On 2010/02/24 01:32:05, pink wrote:
> do you want to validate the width at all? ensure or assert that it's less than
> some upper bound just to be safe?

Added a minimum width for now. Will add maximum...

http://codereview.chromium.org/657038/diff/1/3#newcode105
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:105: -
(NSCursor*)appropriateCursor {
On 2010/02/24 01:32:05, pink wrote:
> needs comment

Done.

http://codereview.chromium.org/657038/diff/1/3#newcode120
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:120: -
(void)mouseDown:(NSEvent*)theEvent {
On 2010/02/24 01:32:05, pink wrote:
> probably needs a comment describing how the drag loop works

Done.

http://codereview.chromium.org/657038/diff/1/3#newcode130
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:130: //
toolbar. Investigate further.
On 2010/02/24 01:32:05, pink wrote:
> file a bug and include the bug# here.

Done.

http://codereview.chromium.org/657038/diff/1/4
File chrome/browser/cocoa/extensions/browser_actions_controller.h (right):

http://codereview.chromium.org/657038/diff/1/4#newcode25
chrome/browser/cocoa/extensions/browser_actions_controller.h:25: @interface
BrowserActionsController : NSObject {
On 2010/02/24 01:32:05, pink wrote:
> Needs a class-level comment.

Done.

http://codereview.chromium.org/657038/diff/1/4#newcode76
chrome/browser/cocoa/extensions/browser_actions_controller.h:76: // Registers
the user preferences used by this class. Static.
On 2010/02/24 01:32:05, pink wrote:
> "static" is implied by the "+", and static isn't used by obj-c for this
purpose,
> so it's an inappropriate description.

Done.

http://codereview.chromium.org/657038/diff/1/5
File chrome/browser/cocoa/extensions/browser_actions_controller.mm (right):

http://codereview.chromium.org/657038/diff/1/5#newcode78
chrome/browser/cocoa/extensions/browser_actions_controller.mm:78: [owner_
resizeContainerWithAnimation:NO];
On 2010/02/24 01:32:05, pink wrote:
> don't you want animation in these cases? Wouldn't it be kinda cool?

Yup. Will be done once it works properly :).

http://codereview.chromium.org/657038/diff/1/5#newcode108
chrome/browser/cocoa/extensions/browser_actions_controller.mm:108: if
(!profile_->GetPrefs()->FindPreference(
On 2010/02/24 01:32:05, pink wrote:
> i don't think we lazily register prefs anywhere else, is this done lazily on
> windows too?

We do in some cases, yes. This is where I got the code.

http://codereview.chromium.org/657038/diff/1/5#newcode172
chrome/browser/cocoa/extensions/browser_actions_controller.mm:172: if
(predefinedWidth != 0)
On 2010/02/24 01:32:05, pink wrote:
> is it worth verifying it's > 0?

This is definitely in progress and will be checked more vigorously.

http://codereview.chromium.org/657038/diff/1/5#newcode248
chrome/browser/cocoa/extensions/browser_actions_controller.mm:248: -
(void)resizeContainerWithAnimation:(BOOL)animate {
On 2010/02/24 01:32:05, pink wrote:
> needs comment

Done.

http://codereview.chromium.org/657038/diff/1/5#newcode259
chrome/browser/cocoa/extensions/browser_actions_controller.mm:259: -
(void)containerFrameChanged {
On 2010/02/24 01:32:05, pink wrote:
> needs comment

Done.

http://codereview.chromium.org/657038/diff/1/5#newcode284
chrome/browser/cocoa/extensions/browser_actions_controller.mm:284: -
(void)containerDragFinished {
On 2010/02/24 01:32:05, pink wrote:
> needs comment

Done.

http://codereview.chromium.org/657038/diff/1/5#newcode299
chrome/browser/cocoa/extensions/browser_actions_controller.mm:299: -
(void)updateDragAbilities {
On 2010/02/24 01:32:05, pink wrote:
> needs comment

Done.

http://codereview.chromium.org/657038/diff/1/6
File chrome/browser/cocoa/toolbar_controller.mm (right):

http://codereview.chromium.org/657038/diff/1/6#newcode607
chrome/browser/cocoa/toolbar_controller.mm:607: if
(![[browserActionsContainerView_ window] isVisible])
On 2010/02/24 01:32:05, pink wrote:
> what if the window is minimized or the app is hidden? will that cause things
to
> be out of sync when the window is brought back to view?

Good point. Will change.

[Mark Mentovai, 2010-03-08 23:29:58]

I reviewed almost all of this, but then it became dinner o’clock.

http://codereview.chromium.org/657038/diff/4001/4002
File chrome/browser/cocoa/extensions/browser_actions_container_view.h (right):

http://codereview.chromium.org/657038/diff/4001/4002#newcode15
chrome/browser/cocoa/extensions/browser_actions_container_view.h:15: // Sent
when a user-initiated drag to resize the container is in progress.
…where “in progress” means that the size has changed, right?

http://codereview.chromium.org/657038/diff/4001/4002#newcode25
chrome/browser/cocoa/extensions/browser_actions_container_view.h:25: // The
frame encompasing the grippy used for resizing the container.
High-level question (and the answer may become apparent as I keep reading):

Does the grippy always show, or only when it needs to?

If “only when it needs to,” how is “when it needs to” defined?

What happens when there are no browser action buttons at all?  No container/no
grippy, right?

http://codereview.chromium.org/657038/diff/4001/4002#newcode54
chrome/browser/cocoa/extensions/browser_actions_container_view.h:54: BOOL
grippyPinned_;
A subtle detail, but don’t think that nobody noticed how you’ve packed the
members of this class in order of their size.  I noticed.  Nice touch.

http://codereview.chromium.org/657038/diff/4001/4003
File chrome/browser/cocoa/extensions/browser_actions_container_view.mm (right):

http://codereview.chromium.org/657038/diff/4001/4003#newcode11
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:11: extern
const NSString* kDragStartedNotification = @"DragStartedNotification";
These names seem a bit generic.  That can bite you.

The symbolic names should probably be in a namespace, renamed to have
BrowserAction in the names, or something else to avoid collisions of one sort.

The strings should probably have “BrowserAction” or something in them to avoid
collisions of another.

http://codereview.chromium.org/657038/diff/4001/4003#newcode28
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:28: -
(NSCursor*) appropriateCursorForGrippy;
nit: elsewhere, there’s no space between the (REturnType) and selectorName.

http://codereview.chromium.org/657038/diff/4001/4003#newcode101
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:101:
[[NSAnimationContext currentContext] setDuration:0.1];
A constant for 0.1?

http://codereview.chromium.org/657038/diff/4001/4003#newcode105
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:105: [self
setFrame:newFrame];
Do you need to worry about animations already in progress in this case?

http://codereview.chromium.org/657038/diff/4001/4003#newcode120
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:120: return
!canDragLeft_ ? [NSCursor resizeRightCursor] :
I have a hard time figuring out precedence inside nested ternaries, and I’m a
freakin’ genius.  Seriously, I’m the voice of this generation of this decade.

Can you group with (parentheses) for clarity, or rewrite this in terms of a more
traditional if-based logic flow?

Imma let you finish.

http://codereview.chromium.org/657038/diff/4001/4003#newcode147
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:147: // This
inner run loop catches and removes mouse up and drag events from the
Is this right?  Aren’t there other events that you want to catch here and break
out of the loop on?  For example, a right mouse down, maybe?  (Try a few
different types of resizes and see what the typical behavior for right mouse and
button 3 down and other things are.)

http://codereview.chromium.org/657038/diff/4001/4003#newcode152
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:152: [NSApp
nextEventMatchingMask:NSLeftMouseUpMask | NSLeftMouseDraggedMask
Custom run loops are a tiny bit scary.

http://codereview.chromium.org/657038/diff/4001/4003#newcode179
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:179: CGFloat
withDelta = location.x - dX;
withDelta seems like a weird name.  I suspect you meant “widthDelta.”

http://codereview.chromium.org/657038/diff/4001/4003#newcode181
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:181:
canDragRight_ = withDelta >= initialDragPoint_.x;
I guess this is right, but I don’t yet know enough about who else is maintaining
canDragRight_.

It seems a bit odd that you reset canDragRight_ here but not canDragLeft_.

http://codereview.chromium.org/657038/diff/4001/4005
File chrome/browser/cocoa/extensions/browser_actions_controller.mm (right):

http://codereview.chromium.org/657038/diff/4001/4005#newcode179
chrome/browser/cocoa/extensions/browser_actions_controller.mm:179: // The width
will never be 0 (due to container min size restriction)
min -> minimum, and this text is a little rough around the edges too.

http://codereview.chromium.org/657038/diff/4001/4005#newcode208
chrome/browser/cocoa/extensions/browser_actions_controller.mm:208: if
(!buttonKey)
When will this happen?

(It’s OK, I’m just curious if you added it for a reason.)

http://codereview.chromium.org/657038/diff/4001/4005#newcode262
chrome/browser/cocoa/extensions/browser_actions_controller.mm:262:
(kBrowserActionWidth + kBrowserActionButtonPadding));
The is might read a little bit more cleanly if you can get the two factors that
you're multiplying onto the same line…

    w = kGXO + kCP +
        bC * (kBAW + kBABP);

[Bons, 2010-03-09 20:19:51]

http://codereview.chromium.org/657038/diff/4001/4002
File chrome/browser/cocoa/extensions/browser_actions_container_view.h (right):

http://codereview.chromium.org/657038/diff/4001/4002#newcode15
chrome/browser/cocoa/extensions/browser_actions_container_view.h:15: // Sent
when a user-initiated drag to resize the container is in progress.
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> …where “in progress” means that the size has changed, right?

altered the comment to be more clear.

http://codereview.chromium.org/657038/diff/4001/4002#newcode25
chrome/browser/cocoa/extensions/browser_actions_container_view.h:25: // The
frame encompasing the grippy used for resizing the container.
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> High-level question (and the answer may become apparent as I keep reading):
> 
> Does the grippy always show, or only when it needs to?
> 
> If “only when it needs to,” how is “when it needs to” defined?
> 
> What happens when there are no browser action buttons at all?  No container/no
> grippy, right?

Grippy always shows if there are browser actions. Otherwise does not show at
all.

http://codereview.chromium.org/657038/diff/4001/4002#newcode54
chrome/browser/cocoa/extensions/browser_actions_container_view.h:54: BOOL
grippyPinned_;
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> A subtle detail, but don’t think that nobody noticed how you’ve packed the
> members of this class in order of their size.  I noticed.  Nice touch.

I had originally just grouped by type. Are there benefits to packing according
to type size?

http://codereview.chromium.org/657038/diff/4001/4003
File chrome/browser/cocoa/extensions/browser_actions_container_view.mm (right):

http://codereview.chromium.org/657038/diff/4001/4003#newcode11
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:11: extern
const NSString* kDragStartedNotification = @"DragStartedNotification";
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> These names seem a bit generic.  That can bite you.
> 
> The symbolic names should probably be in a namespace, renamed to have
> BrowserAction in the names, or something else to avoid collisions of one sort.
> 
> The strings should probably have “BrowserAction” or something in them to avoid
> collisions of another.

Done.

http://codereview.chromium.org/657038/diff/4001/4003#newcode28
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:28: -
(NSCursor*) appropriateCursorForGrippy;
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> nit: elsewhere, there’s no space between the (REturnType) and selectorName.

Done.

http://codereview.chromium.org/657038/diff/4001/4003#newcode101
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:101:
[[NSAnimationContext currentContext] setDuration:0.1];
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> A constant for 0.1?

Done.

http://codereview.chromium.org/657038/diff/4001/4003#newcode105
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:105: [self
setFrame:newFrame];
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> Do you need to worry about animations already in progress in this case?
I actually don't have animations turned on for this change because I want the
basic functionality down. Added a TODO to make sure I get back to it.

http://codereview.chromium.org/657038/diff/4001/4003#newcode120
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:120: return
!canDragLeft_ ? [NSCursor resizeRightCursor] :
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> I have a hard time figuring out precedence inside nested ternaries, and I’m a
> freakin’ genius.  Seriously, I’m the voice of this generation of this decade.
> 
> Can you group with (parentheses) for clarity, or rewrite this in terms of a
more
> traditional if-based logic flow?
> 
> Imma let you finish.
I'll just write it in asm. That should be more readable.

http://codereview.chromium.org/657038/diff/4001/4003#newcode147
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:147: // This
inner run loop catches and removes mouse up and drag events from the
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> Is this right?  Aren’t there other events that you want to catch here and
break
> out of the loop on?  For example, a right mouse down, maybe?  (Try a few
> different types of resizes and see what the typical behavior for right mouse
and
> button 3 down and other things are.)

I'll do more testing and change the logic. I believe this was copied almost
directly from the tab dragging code.

http://codereview.chromium.org/657038/diff/4001/4003#newcode152
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:152: [NSApp
nextEventMatchingMask:NSLeftMouseUpMask | NSLeftMouseDraggedMask
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> Custom run loops are a tiny bit scary.
Agreed. The issue is that the cursor keeps getting reset and does not persist
(see the TODO) and this is one of my proposed solutions. Any advice on this
would be awesome.

http://codereview.chromium.org/657038/diff/4001/4003#newcode179
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:179: CGFloat
withDelta = location.x - dX;
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> withDelta seems like a weird name.  I suspect you meant “widthDelta.”
No, withDelta is correct. It's taking into account the dX above it.

http://codereview.chromium.org/657038/diff/4001/4003#newcode181
chrome/browser/cocoa/extensions/browser_actions_container_view.mm:181:
canDragRight_ = withDelta >= initialDragPoint_.x;
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> I guess this is right, but I don’t yet know enough about who else is
maintaining
> canDragRight_.
> 
> It seems a bit odd that you reset canDragRight_ here but not canDragLeft_.

Good point. I'll definitely be changing this, though as you can current drag the
container off the screen with this current logic.

http://codereview.chromium.org/657038/diff/4001/4005
File chrome/browser/cocoa/extensions/browser_actions_controller.mm (right):

http://codereview.chromium.org/657038/diff/4001/4005#newcode179
chrome/browser/cocoa/extensions/browser_actions_controller.mm:179: // The width
will never be 0 (due to container min size restriction)
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> min -> minimum, and this text is a little rough around the edges too.
This is what I get for copying a linux comment. Sigh.

http://codereview.chromium.org/657038/diff/4001/4005#newcode208
chrome/browser/cocoa/extensions/browser_actions_controller.mm:208: if
(!buttonKey)
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> When will this happen?
> 
> (It’s OK, I’m just curious if you added it for a reason.)
If the extension id is not valid UTF8, then the NSString will be nil and won't
that make things go boom if I do a setObject forKey:nil ?

http://codereview.chromium.org/657038/diff/4001/4005#newcode262
chrome/browser/cocoa/extensions/browser_actions_controller.mm:262:
(kBrowserActionWidth + kBrowserActionButtonPadding));
On 2010/03/08 23:29:59, Mark Mentovai wrote:
> The is might read a little bit more cleanly if you can get the two factors
that
> you're multiplying onto the same line…
> 
>     w = kGXO + kCP +
>         bC * (kBAW + kBABP);

Done.

[Mark Mentovai, 2010-03-09 23:08:37]

Spot-check looks OK.