Add Mouse hover behavior to Mac Panels when minimized

chrome/browser/ui/panels/native_panel.h

Index: chrome/browser/ui/panels/native_panel.h
diff --git a/chrome/browser/ui/panels/native_panel.h b/chrome/browser/ui/panels/native_panel.h
index d25ae213c7a4f701fd19abd24679dff2b4b300e6..08d82e4df14e2f6b3003642b668c6579225eeaa6 100644
--- a/chrome/browser/ui/panels/native_panel.h
+++ b/chrome/browser/ui/panels/native_panel.h
@@ -87,6 +87,7 @@ class NativePanel {
 class NativePanelTesting {
  public:
   static NativePanelTesting* Create(NativePanel* native_panel);
+  // TODO(dimich) Remove this method, there is PanelMouseWatcher::GetInstance().

[prasadt, 2011/09/21 16:54:15]

We don't compile the implementation of GetInstance into all the platforms. 
Using that directly in the test will make you to choose between some not so
great alternatives:
1) Exclude panel_browsertest.cc on certain platforms
2) Add a .cc file for each platform just to include a dummy defintion.
3) Use #if in panel_mouse_watcher.h file to include a dummy definition for some
platforms.

Using PanelMouseWatcher::GetInstance() was what was causing the build break. 
Having this method in NativePanelTesting seemed to me the best alternative. 
Just FYI, not to say it can't be improved upon.

[jennb, 2011/09/21 17:48:19]

The build break was because there was no implementation of
PanelMouseWatcher::GetInstance on all platforms. Once we have that, it will be
safe to remove this. We're not there yet, of course.

[Dmitry Titov, 2011/09/21 20:38:51]

Indeed. With GetInstance() implemented on all platforms, we could just use that.
All Singleton-based classes are usually accessed as FooBar::GetInstance(), we
probably should do the same.

[prasadt1, 2011/09/21 21:33:15]

True but "all platforms" seems to be a bit of a moving target. Do a
auto_hiding_desktop_bar* in the panels directory to see all the platforms that
Jian had to handle to build successfully. "aura" is one of them, I don't know
what exactly it is but we may not be supporting it for a while.
The platform specific implementations of these methods are only accessed from
platform specific code, so there isn't an issue of unresolved symbols. The
platforms that refer to the method would also implement it.

Our case is different because we're accessing this method wich has platform
specific implementations, from panel_browsertest.cc which is platform
independent i.e it gets compiled/linked on all platforms.  This means we need a
dummy implementation for every platform, even "aura" which we may not care
about.  Note that this requirement is not there for building chrome (as opposed
to browser_tests) where we access this method only from platform specific files.

Prasad

[dcheng, 2011/09/21 22:12:41]

Just my two cents, but testing in general seems like one of those things we need
to think about a better story and probably do some refactoring. We have
essentially two different frameworks for testing panels (one Windows views
specific, one platform independent but written from a primarily GTK
point-of-view). The two approaches differ in several ways:
- views uses MessageLoop, browser test uses MessageLoopForUI.
- views prefers to pump the message loop directly in the test, while browser
test abstracts some of that into the testing interface (this means it's not
actually safe to use PanelMouseWatcher's methods directly in the browser test,
you need to go through NativePanelTesting)
- The set of hooks and entry points into the interfaces are somewhat different.

It just seems like there's room for consolidation here.

   static PanelMouseWatcher* GetPanelMouseWatcherInstance();
 
   // clang gives error on delete if the destructor is not virtual.