diff options
author | danakj@chromium.org <danakj@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-10-04 15:14:56 +0000 |
---|---|---|
committer | danakj@chromium.org <danakj@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-10-04 15:14:56 +0000 |
commit | 7607b37a291cc77aab7837eb41b4cc3da509b5f3 (patch) | |
tree | 15a31e82d2e2ddb2c9e17d9dbfa532e18070d344 /views/widget/native_widget_gtk.cc | |
parent | 54e5a332da69a54444a016d360f810ce749fdf17 (diff) | |
download | chromium_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.cc | 9 |
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()); } //////////////////////////////////////////////////////////////////////////////// |