“Launcher” is the user-visible name for this feature.
//ash/app_list contains the view structure and data model. Before 2018 this code lived in //ui/app_list because the app list used to be supported on non-Chrome OS platforms.
//chrome/browser/ash/app_list contains app list code that has Profile dependencies. This includes sync support and communication with the App Service (which provides the list of installed apps).
The list of installed apps is provided by the App Service. It includes a variety of app types:
Some of a user's apps might not be supported on their current device. For example, a user might have a device that does not support Crostini. Likewise, they might have a device on a new OS version (e.g. dev channel) that includes a new built-in app but also have devices on older OS versions that do not support that app.
Unsupported apps are not shown in the app list.
See the AppListSpecifics protocol buffer
Note that the sync data does not contain which page an app is on, nor the app's position within a page.
For the app list, an ordinal is a string type that allows ordering and insertion without rewriting existing items. For example, with ordinals “aa” and “bb” you can create an ordinal “am” that sorts to the middle, without changing “aa” or “bb”.
ash::AppListModel is the core data model. There is a single copy of this model, owned by ash.
AppListModel owns an AppListItemList for the top-level grid of apps. AppListItemList contains items in the order they appear in the app list, across across all pages.
Each AppListItem contains AppListItemMetadata. The data is similar to the data provided by sync, but is more focused on display. As of March 2021 the data includes:
The ash data model is not directly exposed to code in //chrome. Chrome has its own data about each item, with ChromeAppListModelUpdater owning a map of ChromeAppListItem. These items use the same metadata as AppListItem. This separation is left over from the mustash project, where code in //ash and //chrome used to run in separate processes, and hence could not directly share a model. See go/move-applist.
AppListFolderItem is a subclass of AppListItem. Each folder has its own AppListItemList. Items inside of folders do not appear in the top-level item list.
Folders do not contain page breaks. Each page must be filled before the next page is created.
While items inside a folder can be reordered, the order data is not persisted to sync.
An AppListItemView represents each app. It is a button and has an image icon and a name label.
AppsGridView displays a grid of AppListItemViews. An AppsGridView is used to show the main app grid. A separate AppsGridView is used to show the contents of a folder.
AppsGridView has an AppListItemView for each app in the main list, even those that are not on the current page (and hence are not visible). AppsGridView also contains a PaginationModel, which has a list of views for each visual page.
When a folder is open, its AppListFolderView is stacked on top of the main apps grid view. Only one folder can be open at a time. The folder view contains its own AppsGridView.
Therefore the view hierarchy is approximately this:
You can run chrome with --ash-debug-shortcuts, open the launcher, and press Ctrl-Alt-Shift-V to see the full view hierarchy.
App list tests live in ash_unittests. Run the unit tests with:
testing/xvfb.py out/Default/ash_unittests
Tests for high level user actions (reordering icons, creating folders, etc.) are generally part of apps_grid_view_unittest.cc or app_list_presenter_delegate_unittest.cc.
The old demo binary in //ash/app_list/demo was removed in 2021.
The shelf was originally called the launcher (circa 2012).