chromium/src
0
Fork 0
Code Activity
Files
7d842a22345b74f991d6b3a6568b03cd1a6bba3c
src/docs/ui/views/macviews_release.md
lgarron 617a30f35e Rename WebsiteSettings code to PageInfo. 
This was automated using a script [1] that does the following:
- Rename relevant files in the following folders from website_settings* to
  page_info*:
  - chrome/browser/ui/page_info
  - chrome/browser/ui/cocoa/page_info
  - chrome/browser/ui/views/page_info
  - chrome/browser/ui/android/page_info
  - chrome/android/java/res/layout
- Run `./tools/git/mass-rename.py` to update e.g. includes, build files, header
  guards.
  - mass-rename.py does not handle test files (https://crbug.com/701529) or
    Java, so those are handled separately, either in an early step are as part
    of the later renames.
  - `page_info_bubble_controller.h` needs a separate header guard fix.
- Use `sed` to rename classes, enums, non-UMA strings, and comments *WebsiteSettings* to *PageInfo* across the entire Chromium project.
  - Since several content settings classes are also called "WebsiteSettings", this is done by taking a full list of all occurrences of full tokens containing "WebsiteSettings", "website_settings", or "website settings" and whitelisting individual replacements.
  - To avoid modifying strings, all lines containing the relevant tokens *following at least one quote mark on the same line* are preserved, except two individually handled cases. There do not appear to be any affected multi-line strings.
- `git cl format`
- Remove two long-standing TODO comments about this rename, in:
  - PageInfoPopup.java
  - page_info_bubble_controller.h

This CL does not attempt to reflow comments; all changes stay within 80 lines, though.

[1] https://github.com/lgarron/website-settings-to-page-info/blob/master/page_info.fish

BUG=571506
TBR=jochen@chromium.org

Review-Url: https://codereview.chromium.org/2754383004
Cr-Commit-Position: refs/heads/master@{#459562}
2017-03-24 21:42:07 +00:00

3.4 KiB
Raw Blame History

MacViews Release Plan

Handy Links

Phase 1: Controls

Implement Shiny Modern L&F for individual controls, most-commonly-used first. In rough order:

  1. Buttons
  2. Editboxes
  3. Comboboxes
  4. Radiobuttons/checkboxes
  5. Menubuttons
  6. Treeviews
  7. Tableviews

This phase overlaps with phase 2.

Phase 2: WebUI Cocoa Dialogs, Rubberband

Once enough controls are done, wire up the Views versions of WebUI-styled Cocoa dialogs, behind a new MacViewsWebUIDialogs feature. The WebUI-styled Cocoa dialogs are:

  1. Collected/blocked cookies UI
  2. Device permissions
  3. Extension install
  4. HTTP auth
  5. One-click signin
  6. Site permissions bubble
  7. "Card unmask prompt" (TODO(ellyjones): what is this?)
  8. Page info dialog

Once all of these dialogs are converted and tested behind the feature, we can ship to canary and dev channels and watch for any performance or crash rate regressions. Doing all the WebUI-style dialogs at once will avoid having three separate dialog UIs.

This phase also includes implementation of rubber-band overscroll and fling scrolling. This technology exists already in the renderer compositor - it needs to be transplanted to the ui compositor.

Phase 3: The Other Dialogs

Once WebUI dialogs are converted en masse, we can convert other dialogs to Views individually, and ship them without a flag flip or field trial. Cocoa dialogs that are in native Cocoa style will gradually migrate to Views dialogs that are in the Shiny Modern style.

Phase 4: Omnibox & Top Chrome

At this point, all dialogs are in Shiny Modern, but the rest of the browser chrome is still Cocoa.

Implement Cocoa L&F for any controls still needed for omnibox and top chrome. TODO(ellyjones): which controls are these? Implement Views versions of the omnibox and top chrome behind a new flag mac-views-browser-chrome. Get UI review of the new versions of the omnibox and top chrome. Make the Views versions the default.

Phase 5: mac_views_browser=1

At this point, all user-visible UI is done via Views, and we need to switch the entire browser to a Views-only build:

Check for performance regressions against mac_views_browser=0. Check for stability regressions against mac_views_browser=0. Check for a11y regressions through manual testing. TODO(ellyjones): Figure out how feasible automated a11y regression testing is. Switch mac_views_browser to 1 for Canary. Cross fingers. Watch metrics carefully. If there's no surprising metrics changes or public outcry, keep mac_views_browser=1 for dev, then beta, then stable.

Phase 6: delete Cocoa

Since much of the Cocoa code is dead and we are no longer building with mac_views_browser=0, remove dead Cocoa UI code.