ChromeOS: Avoid overlapping app list with virtual keyboard.

ui/app_list/views/app_list_view.cc

Index: ui/app_list/views/app_list_view.cc
diff --git a/ui/app_list/views/app_list_view.cc b/ui/app_list/views/app_list_view.cc
index 4924eb94504f515821c1d83c180ae4488c036d45..6d3f20a10b791cb245a0a4eec5aa11569d55b85d 100644
--- a/ui/app_list/views/app_list_view.cc
+++ b/ui/app_list/views/app_list_view.cc
@@ -360,6 +360,13 @@ void AppListView::InitAsBubbleInternal(gfx::NativeView parent,
 gfx::Point AppListView::GetCenterPoint() {
   DCHECK(screen_to_keep_centered_on_);
   gfx::Rect bounds = screen_to_keep_centered_on_->GetPrimaryDisplay().bounds();

[tapted, 2014/04/29 03:39:17]

Can we just center in the WorkArea rather than bounds()?

shelf_layout_manager.cc seems to subtract the keyboard from the work area around
line 842.

i.e. just a 1-line change here:

gfx::Rect bounds = screen_to_keep_centered_on_->GetPrimaryDisplay().work_area();

[Matt Giuca, 2014/04/29 05:51:35]

Hmm... unfortunately it looks like the order is wrong. If I make this change,
the app list doesn't move when opening the keyboard. But it does move upwards on
subsequent updates (like closing the keyboard). Basically,
AppListView::UpdateBounds is being called before
ShelfLayoutManager::CalculateTargetBounds.

I've had a look at the stack traces, and they don't have a lot in common (it
won't be easy to change this order around). I think we should just stick with
the code I had. (Pity, it was a good suggestion.)

[tapted, 2014/04/29 06:09:53]

Drat. Maybe a short note here like

  // Can't use Display::work_area() because it is updated after UpdateBounds().

[Matt Giuca, 2014/04/29 06:26:11]

Done.

+
+  // If the virtual keyboard is active, subtract it from the display bounds, so
+  // that the app list is centered in the non-keyboard area of the display.
+  gfx::Rect keyboard_bounds = delegate_->GetVirtualKeyboardBounds();
+  if (!keyboard_bounds.IsEmpty())
+    bounds.Subtract(keyboard_bounds);
+
   return bounds.CenterPoint();
 }