Make the resize gripper invisible....

Make the resize gripper invisible.

BUG=50107
TEST=Resize gripper nest to browser actions container should no longer appear

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

[Peter Kasting, 2010-07-26 20:36:06]

I'll also remove resize_gripper.png in this change.

[Peter Kasting, 2010-07-26 20:38:20]

Added estade to review the GTK bit.  There's probably more simplification that
can happen than what I've done.

[Evan Stade, 2010-07-26 20:41:15]

http://codereview.chromium.org/3052011/diff/1/3
File chrome/browser/gtk/browser_actions_toolbar_gtk.cc (left):

http://codereview.chromium.org/3052011/diff/1/3#oldcode757
chrome/browser/gtk/browser_actions_toolbar_gtk.cc:757: if (!draw_gripper_)
you can get rid of all references to draw_gripper_

[Peter Kasting, 2010-07-26 20:58:13]

New snap up.  I also removed a "gtk_widget_queue_draw()" call.

http://codereview.chromium.org/3052011/diff/1/3
File chrome/browser/gtk/browser_actions_toolbar_gtk.cc (left):

http://codereview.chromium.org/3052011/diff/1/3#oldcode757
chrome/browser/gtk/browser_actions_toolbar_gtk.cc:757: if (!draw_gripper_)
On 2010/07/26 20:41:15, Evan Stade wrote:
> you can get rid of all references to draw_gripper_

Done.

[Finnur, 2010-07-26 21:02:47]

http://codereview.chromium.org/3052011/diff/1/4
File chrome/browser/views/browser_actions_container.cc (left):

http://codereview.chromium.org/3052011/diff/1/4#oldcode524
chrome/browser/views/browser_actions_container.cc:524: 
I take it you've tried starting with no extension and installing one with a
browser action (and verify it becomes visible)? Or starting with 1 and
uninstalling it?

http://codereview.chromium.org/3052011/diff/1/5
File chrome/browser/views/browser_actions_container.h (right):

http://codereview.chromium.org/3052011/diff/1/5#newcode189
chrome/browser/views/browser_actions_container.h:189: // 1) An invisible resize
area.
Make sure you circle back with Nicolas J. on this. As I understood Nicolas, he
wanted the edge of the location bar view (and 3 pixels in each way horizontally)
to be draggable, as opposed to the empty area left of the container. That way
you get rid of some padding around the browser actions.

Note: I'm fine with either outcome.

http://codereview.chromium.org/3052011/diff/1/6
File chrome/browser/views/extensions/extension_installed_bubble.cc (right):

http://codereview.chromium.org/3052011/diff/1/6#newcode29
chrome/browser/views/extensions/extension_installed_bubble.cc:29: #include
"views/controls/image_view.h"
Is this intentional? Not against it, just curious.

[Peter Kasting, 2010-07-26 21:14:43]

http://codereview.chromium.org/3052011/diff/1/4
File chrome/browser/views/browser_actions_container.cc (left):

http://codereview.chromium.org/3052011/diff/1/4#oldcode524
chrome/browser/views/browser_actions_container.cc:524: 
On 2010/07/26 21:02:47, Finnur wrote:
> I take it you've tried starting with no extension and installing one with a
> browser action (and verify it becomes visible)? Or starting with 1 and
> uninstalling it?

It's always "visible" in the Views sense, since we removed the SetVisible(false)
call in the BrowserActionsContainer constructor, and true is the default.

(Of course, since it doesn't draw anything, it's never "visible" to the user.)

http://codereview.chromium.org/3052011/diff/1/5
File chrome/browser/views/browser_actions_container.h (right):

http://codereview.chromium.org/3052011/diff/1/5#newcode189
chrome/browser/views/browser_actions_container.h:189: // 1) An invisible resize
area.
On 2010/07/26 21:02:47, Finnur wrote:
> Make sure you circle back with Nicolas J. on this. As I understood Nicolas, he
> wanted the edge of the location bar view (and 3 pixels in each way
horizontally)
> to be draggable, as opposed to the empty area left of the container.

There are to be 4 px padding between the omnibox and first browser action, all
of which should function as a resizer.  (This patch makes the width 4 px and the
resizer invisible but doesn't yet move the next browser action adjacent to the
resizer; that will come later.)

Nicholas would _also_ like the edge of the omnibox and a few px in to be part of
the resize area.  This doesn't do that, and in fact none of my local changes do
it yet, as I'm not sure how to accomplish it in a safe and robust way
(overlapping the views can cause event dispatch strangeness).

http://codereview.chromium.org/3052011/diff/1/6
File chrome/browser/views/extensions/extension_installed_bubble.cc (right):

http://codereview.chromium.org/3052011/diff/1/6#newcode29
chrome/browser/views/extensions/extension_installed_bubble.cc:29: #include
"views/controls/image_view.h"
On 2010/07/26 21:02:47, Finnur wrote:
> Is this intentional? Not against it, just curious.

Yes:
* Since ImageView is used below, theoretically the file should be including it
anyway regardless of what other files may already #include it.
* Practically, the indirect #include through
browser_actions_container.h->resize_gripper.h was the only real #include, so
without this change, things stop compiling.

[Finnur, 2010-07-26 21:19:35]

LGTM

http://codereview.chromium.org/3052011/diff/1/4
File chrome/browser/views/browser_actions_container.cc (left):

http://codereview.chromium.org/3052011/diff/1/4#oldcode524
chrome/browser/views/browser_actions_container.cc:524: 
Oh, right...

On 2010/07/26 21:14:43, Peter Kasting wrote:
> On 2010/07/26 21:02:47, Finnur wrote:
> > I take it you've tried starting with no extension and installing one with a
> > browser action (and verify it becomes visible)? Or starting with 1 and
> > uninstalling it?
> 
> It's always "visible" in the Views sense, since we removed the
SetVisible(false)
> call in the BrowserActionsContainer constructor, and true is the default.
> 
> (Of course, since it doesn't draw anything, it's never "visible" to the user.)

[Evan Stade, 2010-07-26 21:29:11]

lgtm