Some subdirs have their own .style.yapf files (like
//testing/pytype_common/), but most do not. This has lead to a lot of
python code in //testing/ naturally being developed with no
consistent styling. This can make things a little hard to read when
put in the context of other py code throughout the repo that's much
more consistent.
So this:
- adds a basic //testing/.style.yapf file
- adds another testing/trigger_scripts/.style.yapf file that's similar
but sets indent to 4, since the code in that dir currently uses
4 indents
- reformats everything
- adds a presubmit checkout to //testing/PRESUBMIT.py to enforce that
things stay formatted
Bug: 340623285
Change-Id: I2a6707ba2f6f784454d348a19280dca2ca90804b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5540460
Commit-Queue: Ben Pastene <bpastene@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1301583}
Seeing failures from calibration waterfall (and fixed by crrev.com/c/3199782). Adding more conversion on the other files in the same folder.
Bug: chromium:1252452
Change-Id: I58a25872c8d997f0714a769fbf0d1bd79d6fb8d4
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3202582
Commit-Queue: Wenbin Zhang <wenbinzhang@google.com>
Reviewed-by: John Chen <johnchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#927976}
When GLVisualPickerGLX was written, the only way of obtaining
GL-compatible visuals was with libGLX, which loads the GPU driver.
This forced us to rely on the GPU process sending the visuals to the
browser process, which comes with a significant amount of complexity.
Now that we've switched to XProto, we can use x11::Glx to obtain the
visuals, which doesn't require loading the GPU driver. This allows
us to simplify the visual loading code.
In addition, now that the transparent visual is available early, it
can be used as the visual for browser windows. This can allow us to
remove usage of the XShape extension which we were using to "cut off"
a few pixels around the corners to give the appearance of rounded
corners. This solution is not ideal since it:
1. causes a performance hit on some environments (GNOME/Mutter)
2. prevents the WM from drawing a shadow on the window
3. doesn't antialias the corners
Using a transparent visual will solve all 3 issues. However, we'll
have to draw client-side shadows (just like GTK does).
R=sky
Bug: 650494,811515,1198080
Change-Id: Ie518dfe489d3ba0af9ca73c80cc10792a4214838
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2895228
Reviewed-by: Dirk Pranke <dpranke@google.com>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Emily Stark <estark@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Thomas Anderson <thomasanderson@chromium.org>
Commit-Queue: Emily Stark <estark@chromium.org>
Auto-Submit: Thomas Anderson <thomasanderson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#884257}
