summaryrefslogtreecommitdiffstats
path: root/views/widget/native_widget_gtk.cc
diff options
context:
space:
mode:
authordanakj@chromium.org <danakj@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-10-04 15:14:56 +0000
committerdanakj@chromium.org <danakj@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-10-04 15:14:56 +0000
commit7607b37a291cc77aab7837eb41b4cc3da509b5f3 (patch)
tree15a31e82d2e2ddb2c9e17d9dbfa532e18070d344 /views/widget/native_widget_gtk.cc
parent54e5a332da69a54444a016d360f810ce749fdf17 (diff)
downloadchromium_src-7607b37a291cc77aab7837eb41b4cc3da509b5f3.zip
chromium_src-7607b37a291cc77aab7837eb41b4cc3da509b5f3.tar.gz
chromium_src-7607b37a291cc77aab7837eb41b4cc3da509b5f3.tar.bz2
Make the CROS browser size itself to the MonitorWorkAreaNearestWindow again,
but fix the WorkArea's dimensions to be sane. CL http://codereview.chromium.org/8060016/ changed the CROS browser size to be the MonitorArea, to match the size chosen for the CROS container window. However, sky@ has taken issue with this approach, as this changes the browser window's behavior and may have unexpected consequences down the road when this change is long forgotten. Thus changing back to use the MonitorWorkArea*. However, the MonitorWorkArea is supposed to be a working space on a single monitor. What was being returned was one of 1) The root window dimensions (covers all monitors) 2) The _NET_WORK_AREA, a rect set by the WM that likely covers all monitors (though this is not specified) A rect that covers all monitors is bad as this is always >= the rect given by MonitorArea - the size of the container window - and we get a browser window that is bigger than its container. There is lots of room for multihead here, and that will come in time, this does not attempt to address anything of the sort. We just make MonitorWorkArea() return the same rect as MonitorArea(). This matches all other OS/Toolkit implementations, where the idea of _NET_WORK_AREA does not exist. This does change a few things, which used WorkArea, which may seem odd in a single monitor case, - views/widget/native_widget_gtk.cc:997: This will center on the monitor now instead of on the space inside the user's panels (if this change is noticable at all). However, this also means it will center on a single monitor now in a dual-head environment rather than across them which is a rather bad default behaviour. This is a shortcoming of the spec, and outside of what _NET_WORK_AREA was meant to provide, so we should determine this area on our own if we want it to differ from the monitor's physical area. R=sky,oshima BUG= TEST= Review URL: http://codereview.chromium.org/8070009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@103895 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'views/widget/native_widget_gtk.cc')
-rw-r--r--views/widget/native_widget_gtk.cc9
1 files changed, 8 insertions, 1 deletions
diff --git a/views/widget/native_widget_gtk.cc b/views/widget/native_widget_gtk.cc
index 6ca4190..7c52a57 100644
--- a/views/widget/native_widget_gtk.cc
+++ b/views/widget/native_widget_gtk.cc
@@ -1356,7 +1356,14 @@ bool NativeWidgetGtk::ConvertPointFromAncestor(
}
gfx::Rect NativeWidgetGtk::GetWorkAreaBoundsInScreen() const {
- return gfx::Screen::GetMonitorWorkAreaNearestWindow(GetNativeView());
+ ViewsDelegate *delegate = ViewsDelegate::views_delegate;
+ if (delegate && delegate->GetDefaultParentView()) {
+ // For views-desktop, the work area is the entire space inside this
+ // containter window.
+ return gfx::Rect(gfx::Point(0, 0),
+ delegate->GetDefaultParentView()->size());
+ } else
+ return gfx::Screen::GetMonitorWorkAreaNearestWindow(GetNativeView());
}
////////////////////////////////////////////////////////////////////////////////