Deprecate sheets

So what's going to replace the Sheet component? I can see many use cases for sheets, especially on the desktop where a full-size, app page is not the best option.

There is no direct replacement... the controls and views are distributed differently than that throughout the interfaces. It won't be a 1:1 swap with anything.

I had a chat with John and it might be that contentHub uses sheets at the moment. If that is not the case we can deprecate the sheets.

Note that if contentHub (or other apps) use sheets now, then the deprecation will only be delayed until we have resources to update the designs (+code) for those apps not to use sheets any more.

we are deprecating the sheets.

It will not break apps that use them, but it prints a warning message on console if they are being used, and Sheets will be removed from the API docs.

The System Settings designs use sheets in these places:
* Background: "Preview" and "Choose area" (because otherwise, noticing and then undoing a poor choice would be tedious)
* Language & Text: "Display language" (because otherwise, undoing a mistaken choice would require navigating a UI written in a language that you probably can't even read)
* Network, "Custom Internet APN" and "Custom MMS APN" (because instant-apply could have weird effects)
* Network, "Connect to Other Network" (because it necessarily contains too much stuff to fit in a partial-screen dialog)
* Security & Privacy, "Switch to Passphrase" from passcode and vice versa (ditto)
* Security & Privacy, "Change SIM PIN" (ditto)
* Updates, "Get On Wi-Fi" (so that you are guaranteed to return to the error screen after connecting)
* Updates, "Installing update" for a system update (though this might be a one-off screen).

The Online Accounts design also uses a sheet with a "Cancel" button for embedding the authorization Web page. And once the phone allows connecting to Wi-Fi captive portals, the login page, too, will likely be embedded in a sheet.

As far as I know, the toolkit contains no suitable replacement for any of these. Some of them occur within page stacks, but using a page for those particular things would be misleading, because it would suggest that they are instant-apply like the rest of the stack when they can't be.

I am not pining for this particular API. That snap decisions, dialogs, and sheets are three different APIs is a profound problem. (Most obviously, something that is a full-screen sheet on a phone should often be a partial-screen dialog on a tablet, and even if it is a sheet on a tablet it should almost always be a dialog on a PC.) But dropping its API documentation, without documenting a suitable replacement, is not helpful to those implementing System Settings, networking, or Online Accounts.

Fix committed into lp:~ubuntu-sdk-team/ubuntu-ui-toolkit/staging at revision None, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

technically, the use cases that you mention could use a Page on the PageStack. The Page can then have cancel and confirm buttons, and no changes are applied until Confirm is clicked. Whether this is a good idea from a design point-of-view (the Page will be full-window on a desktop), I leave to you guys.

I added this bug to ubuntu-ux.

I addressed that possibility: "Some of them occur within page stacks, but using a page for those particular things would be misleading, because it would suggest that they are instant-apply like the rest of the stack when they can't be." For brevity I omitted that others are not in page stacks at all: "Connect to Other Network" when it is accessed from the indicator, and the probable solution for reauthorizing to an Online Account (bug 1262876).