Disable left/right/maximize for panels.

Disable left/right/maximize for panels.

Ideally we should replace this with a dedicated minimize button and its own tooltip, but given the timeframe, I think this hack will suffice.

BUG=120038
TEST=Ensure that only the minimize function works for Panels


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=128868

[sky, 2012-03-25 22:53:04]

http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
File ash/wm/workspace/frame_maximize_button.cc (right):

http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
ash/wm/workspace/frame_maximize_button.cc:240: if ((!is_left_right_enabled_ &&
(type == SNAP_LEFT || type == SNAP_RIGHT)) ||
Move this to SnapTypeForLocation, otherwise we're going to get inconsistent
behavior. Also, you'll need to update the tooltip too.

http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
File chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc
(right):

http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc:80: if
(frame()->GetNativeWindow()->GetProperty(
Can we be more explicit and look for panels here rather than assuming
kAlwaysOnTopKey equates to not wanting these behaviors?

[stevenjb, 2012-03-25 23:11:37]

Friday was the freeze date for new strings, and really we should make this just
a dedicated minimize button or remove the side arrows (i.e. it already looks a
little odd), so I'm not sure that updating the tooltip is worth the effort.

http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
File ash/wm/workspace/frame_maximize_button.cc (right):

http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
ash/wm/workspace/frame_maximize_button.cc:240: if ((!is_left_right_enabled_ &&
(type == SNAP_LEFT || type == SNAP_RIGHT)) ||
On 2012/03/25 22:53:05, sky wrote:
> Move this to SnapTypeForLocation, otherwise we're going to get inconsistent
> behavior. Also, you'll need to update the tooltip too.

Done.

http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
File chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc
(right):

http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc:80: if
(frame()->GetNativeWindow()->GetProperty(
On 2012/03/25 22:53:05, sky wrote:
> Can we be more explicit and look for panels here rather than assuming
> kAlwaysOnTopKey equates to not wanting these behaviors?

Resizing Panels works fine, but the behavior is broken for always-on-top
windows, which is why I specifically check that property. Also if we change our
minds about making popups always-on-top we won't need to change the logic here
also.

[sky, 2012-03-25 23:21:10]

On Sun, Mar 25, 2012 at 4:11 PM,  <stevenjb@chromium.org> wrote:
> Friday was the freeze date for new strings, and really we should make this
> just
> a dedicated minimize button or remove the side arrows (i.e. it already looks
> a
> little odd), so I'm not sure that updating the tooltip is worth the effort.

The string freeze date is the branch point, so it's Monday.

>
>
>
>
http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
> File ash/wm/workspace/frame_maximize_button.cc (right):
>
>
http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
> ash/wm/workspace/frame_maximize_button.cc:240: if
> ((!is_left_right_enabled_ && (type == SNAP_LEFT || type == SNAP_RIGHT))
> ||
> On 2012/03/25 22:53:05, sky wrote:
>>
>> Move this to SnapTypeForLocation, otherwise we're going to get
>
> inconsistent
>>
>> behavior. Also, you'll need to update the tooltip too.
>
>
> Done.
>
>
>
http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
> File chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc
> (right):
>
>
http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
> chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc:80:
> if (frame()->GetNativeWindow()->GetProperty(
> On 2012/03/25 22:53:05, sky wrote:
>>
>> Can we be more explicit and look for panels here rather than assuming
>> kAlwaysOnTopKey equates to not wanting these behaviors?
>
>
> Resizing Panels works fine, but the behavior is broken for always-on-top
> windows, which is why I specifically check that property. Also if we
> change our minds about making popups always-on-top we won't need to
> change the logic here also.

I thought this logic, but wanting to not snap panels and always on top
was specific to panels?

  -Scott

[stevenjb, 2012-03-26 00:11:08]

On 2012/03/25 23:21:10, sky wrote:
> On Sun, Mar 25, 2012 at 4:11 PM,  <mailto:stevenjb@chromium.org> wrote:
> > Friday was the freeze date for new strings, and really we should make this
> > just
> > a dedicated minimize button or remove the side arrows (i.e. it already looks
> > a
> > little odd), so I'm not sure that updating the tooltip is worth the effort.
> 
> The string freeze date is the branch point, so it's Monday.
> 
Somehow I had Friday in my head. Done.

> >
> >
> >
> >
>
http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
> > File ash/wm/workspace/frame_maximize_button.cc (right):
> >
> >
>
http://codereview.chromium.org/9773009/diff/1/ash/wm/workspace/frame_maximize...
> > ash/wm/workspace/frame_maximize_button.cc:240: if
> > ((!is_left_right_enabled_ && (type == SNAP_LEFT || type == SNAP_RIGHT))
> > ||
> > On 2012/03/25 22:53:05, sky wrote:
> >>
> >> Move this to SnapTypeForLocation, otherwise we're going to get
> >
> > inconsistent
> >>
> >> behavior. Also, you'll need to update the tooltip too.
> >
> >
> > Done.
> >
> >
> >
>
http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
> > File chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc
> > (right):
> >
> >
>
http://codereview.chromium.org/9773009/diff/1/chrome/browser/ui/views/frame/b...
> > chrome/browser/ui/views/frame/browser_non_client_frame_view_aura.cc:80:
> > if (frame()->GetNativeWindow()->GetProperty(
> > On 2012/03/25 22:53:05, sky wrote:
> >>
> >> Can we be more explicit and look for panels here rather than assuming
> >> kAlwaysOnTopKey equates to not wanting these behaviors?
> >
> >
> > Resizing Panels works fine, but the behavior is broken for always-on-top
> > windows, which is why I specifically check that property. Also if we
> > change our minds about making popups always-on-top we won't need to
> > change the logic here also.
> 
> I thought this logic, but wanting to not snap panels and always on top
> was specific to panels?
> 
I have a bad feeling we're going to change this in one place and forget the
other, but done.

[sky, 2012-03-26 01:54:33]

LGTM, but it seems like if we're going to do this long term we should morph the
button into a minimize button since that's all you can do.

[stevenjb, 2012-03-26 01:56:03]

On 2012/03/26 01:54:33, sky wrote:
> LGTM, but it seems like if we're going to do this long term we should morph
the
> button into a minimize button since that's all you can do.

Agreed 100%, but it seems kind of late for that for R19...

[commit-bot: I haz the power, 2012-03-26 04:31:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/stevenjb@chromium.org/9773009/7003

[commit-bot: I haz the power, 2012-03-26 07:13:02]

Change committed as 128868