Refresh top drag/resize handle plans |
||||||
Issue descriptionRecording these for my own benefit: STAGE 1 * Increase height above tabs from 8 DIP to 9 (more accurately, 8 DIP + window border top stroke; check stroke thickness in high DSFs) * Resize handle in top 5 DIPs * Drag handle for next 8 DIPs * Don't do this while maximized (breaks Fitts' Law) * Experiment: hittest active tab before drag handle STAGE 2 * Create separate HWND with WS_POPUP, WS_EX_TOOLWINDOW, WS_EX_LAYERED, all client area, painted with RGBA 0, 0, 0, 1, sized and positioned above the top of the Chrome window * Use this window to create an 8 DIP resize handle (minus Chrome window stroke width) * Use full area above tabs (except window stroke) as drag handle In some ways stage 2 is actually less complicated, but moving the window around in sync with the Chrome window and forwarding events is probably annoying. See Visual Studio 2017 for an example of this trick in action.
,
May 25 2018
,
May 25 2018
,
May 31 2018
,
May 31 2018
Notes: * We're using an 11 DIP drag handle, not 8. * Platforms which provide their own resize handle at the top should just get the 11 DIP drag handle (which would then change how much the drag handle overlaps tabs). The alternate is to extend the drag handle the same distance into the tabstrip everywhere, which will result in a larger drag handle on some platforms. This seems like maybe not the right thing to me but I could be wrong.
,
Jun 1 2018
,
Jun 5 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3cc39b36874c6e226ecb6595a4f7c20c55726ed1 commit 3cc39b36874c6e226ecb6595a4f7c20c55726ed1 Author: Allen Bauer <kylixrd@chromium.org> Date: Tue Jun 05 15:57:27 2018 Shrink the area above tabs and extend drag region into the top of the inactive tabs. Bug: 837014 Change-Id: I0c9bc67018ba84007c6f62e4c29dc7e9ddc65857 Reviewed-on: https://chromium-review.googlesource.com/1076368 Commit-Queue: Allen Bauer <kylixrd@chromium.org> Reviewed-by: Peter Kasting <pkasting@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#564519} [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/ash/public/cpp/ash_layout_constants.cc [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/frame/glass_browser_frame_view.cc [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/frame/opaque_browser_frame_view.cc [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/frame/opaque_browser_frame_view.h [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/frame/opaque_browser_frame_view_layout.cc [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/frame/opaque_browser_frame_view_layout.h [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/frame/opaque_browser_frame_view_layout_unittest.cc [modify] https://crrev.com/3cc39b36874c6e226ecb6595a4f7c20c55726ed1/chrome/browser/ui/views/tabs/tab_strip.cc
,
Jun 7 2018
,
Jun 7 2018
Not sure whether we want to call this fixed until we're confident we have the right behavior here -- it's still pretty raw testing. But I'll leave this alone and Allen can reopen if he thinks that has merit. I will file followup bugs for both the stage 2 route and dealing with this in the themed case (in which case we can't extend down into the tabs), both of which can be separate from this.
,
Jun 8 2018
(Bugs mentioned in comment 9 have now been filed) |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by pkasting@chromium.org
, Apr 25 20182.0 KB
2.0 KB View Download