diff options
Diffstat (limited to 'chrome/browser/ui/cocoa/browser_frame_view.h')
| -rw-r--r-- | chrome/browser/ui/cocoa/browser_frame_view.h | 14 |
1 files changed, 3 insertions, 11 deletions
diff --git a/chrome/browser/ui/cocoa/browser_frame_view.h b/chrome/browser/ui/cocoa/browser_frame_view.h index 42faa9b..1d5a095 100644 --- a/chrome/browser/ui/cocoa/browser_frame_view.h +++ b/chrome/browser/ui/cocoa/browser_frame_view.h @@ -1,13 +1,11 @@ -// Copyright (c) 2009 The Chromium Authors. All rights reserved. +// Copyright (c) 2011 The Chromium Authors. All rights reserved. // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. #import <Cocoa/Cocoa.h> // BrowserFrameView is a class whose methods we swizzle into NSGrayFrame -// (an AppKit framework class) so that we can support custom frame drawing, and -// have the ability to move our window widgets (close, zoom, miniaturize) where -// we want them. +// (an AppKit framework class) so that we can support custom frame drawing. // This class is never to be instantiated on its own. // We explored a variety of ways to support custom frame drawing and custom // window widgets. @@ -20,8 +18,6 @@ // c) We had to be able to support "transparent" themes, so that you could see // through to the underlying windows in places without the system theme // getting in the way. -// d) We had to support having the custom window controls moved down by a couple -// of pixels and rollovers, accessibility, etc. all had to work. // // Since we want "A" we couldn't just do a transparent borderless window. At // least I couldn't find the right combination of HITheme calls to make it draw @@ -30,9 +26,6 @@ // "C" precluded us from inserting a view between the system frame and the // the content frame in Z order. To get the transparency we actually need to // replace the drawing of the system frame. -// "D" required us to override _mouseInGroup to get our custom widget rollovers -// drawing correctly. The widgets call _mouseInGroup on their superview to -// decide whether they should draw in highlight mode or not. // "B" precluded us from just setting a background color on the window. // // Originally we tried overriding the private API +frameViewForStyleMask: to @@ -43,8 +36,7 @@ // class is NOT an instance of NSGrayView (as opposed to a subclass of // NSGrayView) then the system drawing will not work correctly. // -// Given all of the above, we found swizzling drawRect, and adding an -// implementation of _mouseInGroup and updateTrackingAreas, in _load to be the +// Given all of the above, we found swizzling drawRect in _load to be the // easiest and safest method of achieving our goals. We do the best we can to // check that everything is safe, and attempt to fallback gracefully if it is // not. |