Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(505)

Issues Search
    My Issues | Starred     Open | Closed | All

Side by Side Diff: docs/browser_view_resizer.md

Issue 2545363002: Use HTTPS links for Google domains in docs (Closed)
Patch Set: Modify two more files in subdirectories Created 4 years ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
« no previous file with comments | « docs/android_test_instructions.md ('k') | docs/chromium_browser_vs_google_chrome.md » ('j') | no next file with comments »
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
OLDNEW
1 # Browser View Resizer 1 # Browser View Resizer
2 2
3 To fix bug [458](http://code.google.com/p/chromium/issues/detail?id=458), which 3 To fix bug [458](http://code.google.com/p/chromium/issues/detail?id=458), which
4 identifies that it is hard to hit the thin window frame corner to resize the 4 identifies that it is hard to hit the thin window frame corner to resize the
5 window. It would be better to have a resize hit area (called widget from now on) 5 window. It would be better to have a resize hit area (called widget from now on)
6 in the corner, as we currently have for edit boxes for example. 6 in the corner, as we currently have for edit boxes for example.
7 7
8 [TOC] 8 [TOC]
9 9
10 ## Background 10 ## Background
(...skipping 58 matching lines...) Expand 10 before | Expand all | Expand 10 after
69 69
70 ## Design 70 ## Design
71 71
72 Unfortunately, we must deal with the two different cases (with or without a 72 Unfortunately, we must deal with the two different cases (with or without a
73 dynamic bottom view) in two different and distinct ways. 73 dynamic bottom view) in two different and distinct ways.
74 74
75 ### Over a Dynamic View 75 ### Over a Dynamic View
76 76
77 For the cases where there is a dynamic view at the bottom of the browser view, a 77 For the cases where there is a dynamic view at the bottom of the browser view, a
78 new view class (named `BrowserResizerView`) inheriting from 78 new view class (named `BrowserResizerView`) inheriting from
79 [views::View](http://src.chromium.org/svn/trunk/src/chrome/views/view.h) is used 79 [views::View](https://src.chromium.org/svn/trunk/src/chrome/views/view.h) is use d
80 to display the resize widget. It is set as a child of the dynamic view laid at 80 to display the resize widget. It is set as a child of the dynamic view laid at
81 the bottom of the browser view. The Browser view takes care of properly setting 81 the bottom of the browser view. The Browser view takes care of properly setting
82 the bounds of the resize widget view, based on the language direction. 82 the bounds of the resize widget view, based on the language direction.
83 83
84 Also, it is easier and more efficient to let the browser view handle the mouse 84 Also, it is easier and more efficient to let the browser view handle the mouse
85 interactions to resize the browser. We can let Windows take care of properly 85 interactions to resize the browser. We can let Windows take care of properly
86 resizing the view by returning the HTBOTTOMLEFT or HTBOTTOMRIGHT flags from the 86 resizing the view by returning the HTBOTTOMLEFT or HTBOTTOMRIGHT flags from the
87 NCClientHitTest windows message handler when they occur over the resize widget. 87 NCClientHitTest windows message handler when they occur over the resize widget.
88 The browser view also takes care of changing the mouse cursor to the appropriate 88 The browser view also takes care of changing the mouse cursor to the appropriate
89 resizing arrows when the mouse hovers over the resize widget area. 89 resizing arrows when the mouse hovers over the resize widget area.
(...skipping 14 matching lines...) Expand all
104 receives the bitmap rendered by WebKit so it can layer the transparent bitmap 104 receives the bitmap rendered by WebKit so it can layer the transparent bitmap
105 used for the resize widget. That same render widget host view must also handle 105 used for the resize widget. That same render widget host view must also handle
106 the mouse interaction and use the same trick as the browser view to let Windows 106 the mouse interaction and use the same trick as the browser view to let Windows
107 take care of resizing the whole frame. It must also take care of changing the 107 take care of resizing the whole frame. It must also take care of changing the
108 mouse cursor to the appropriate resizing arrows when the mouse hovers over the 108 mouse cursor to the appropriate resizing arrows when the mouse hovers over the
109 resize widget area. 109 resize widget area.
110 110
111 ## Implementation 111 ## Implementation
112 112
113 You can find the changes made to make this work in patch 113 You can find the changes made to make this work in patch
114 [16488](http://codereview.chromium.org/16488). 114 [16488](https://codereview.chromium.org/16488).
115 115
116 ## Alternatives Considered 116 ## Alternatives Considered
117 117
118 We could have tried to reuse the code that currently takes care of resizing the 118 We could have tried to reuse the code that currently takes care of resizing the
119 edit boxes within WebKit, but this code is wired to the overflow style of HTML 119 edit boxes within WebKit, but this code is wired to the overflow style of HTML
120 element and would have been hard to rewire in an elegant way to be used in a 120 element and would have been hard to rewire in an elegant way to be used in a
121 higher level object like the browser view. Unless we missed something. 121 higher level object like the browser view. Unless we missed something.
122 122
123 We might also decide to go with the easier solution of only showing the resize 123 We might also decide to go with the easier solution of only showing the resize
124 corner within the tab contents view. In that case, it would still be recommended 124 corner within the tab contents view. In that case, it would still be recommended
125 that the resize widget would not appear when dynamic views are taking over the 125 that the resize widget would not appear when dynamic views are taking over the
126 bottom portion of the browser view, since it would look weird to have a resize 126 bottom portion of the browser view, since it would look weird to have a resize
127 corner widget that is not in the real... corner... of the browser view ;-) 127 corner widget that is not in the real... corner... of the browser view ;-)
128 128
129 We may decide that we don't want to see the resize widget bitmap hide some 129 We may decide that we don't want to see the resize widget bitmap hide some
130 pixels from the tab contents (or dynamic view) yet we would still have the 130 pixels from the tab contents (or dynamic view) yet we would still have the
131 resizing functionality via the mouse interaction and also get visual feedback 131 resizing functionality via the mouse interaction and also get visual feedback
132 with the mouse cursor changes while we hover over the resize widget area. 132 with the mouse cursor changes while we hover over the resize widget area.
133 133
134 We may do more research to find a way to solve this problem in a single place as 134 We may do more research to find a way to solve this problem in a single place as
135 opposed to the current dual solution, but none was found so far. 135 opposed to the current dual solution, but none was found so far.
OLDNEW
« no previous file with comments | « docs/android_test_instructions.md ('k') | docs/chromium_browser_vs_google_chrome.md » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698