| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the new resize corner. Local experiment led me to believe that it is WebKit
that is slower when we specify a resize corner area.
To validate this hypothesis, I always return an empty rect to WebKit, but I
still compute and push the rect to the render widget and I also draw the bitmap
even if this will cause it to be drawn on top of the scroll bars when there is
only one.
TBR=brettw
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9654 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/21231
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9517 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
Adding proper project dependency in chrome.sln.
Review URL: http://codereview.chromium.org/21188
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9493 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/20190
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9414 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To display a resize bitmap and handle the mouse interactions as requested in
http://code.google.com/p/chromium/issues/detail?id=458.
BUG=458
There are unfortunately two cases to handle and they must be handled separately.
The first one is when there are no bottom shelf like the download bar,
and the case where there is one.
For the case without, we must draw on top of what we receive from WebKit,
so we intercept the bitmap in RenderWidgetHostViewWin::OnPaint() so that we
can draw the resize corner bitmap on top of it (taking into account whether
we are in a right to left language or not).
For the case where we have a bottom shelf, we use a dedicated view that we
properly layout on top of the bottom shelf view (which takes care of handling
the RTL language case for us).
Same split for the mouse interactions. Without the bottom shelf, we must deal
with it in RenderWidgetHostViewWin::OnMouseEvent() by sending the root window
a WM_NCLBUTTONDOWN message with either HTBOTTOMRIGHT or HTBOTTOMLEFT (based on
the RTL setting) and let the OS take care of the resizing. IF we have a bottom
shelf, we must deal with the mouse interaction in
BrowserView::NonClientHitTest()
to either return HTBOTTOMRIGHT or HTBOTTOMLEFT (again, based on the RTL setting)
and, again, let the OS take care of the resizing.
More details here:
http://code.google.com/p/chromium/wiki/BrowserViewResizer
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@9408 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the ability to dock to the following locations:
Maximize the window on drop.
Resize the window to fill up the left, bottom, or right half of the
monitor.
Tile the newly created window with an existing chrome window such that
the two are on top of each other and fill the height of the monitor,
or tiled such that they fill the width of the monitor.
The graphics suxor. Glen says he'll come up with something better once
its landed.
BUG=none
TEST=4628
Review URL: http://codereview.chromium.org/11325
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@5797 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@1287 0039d316-1c4b-4281-b951-d872f2087c98
|
|
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15 0039d316-1c4b-4281-b951-d872f2087c98
|