Repository navigation
"Toast" notifications #8592
Description
An idea I've been toying around with for a while, but haven't formalized.
"Toasts" are an Android UI paradigm - a transient notification that can be displayed to the user. These toasts can't be interacted with, and dismiss themselves after a brief timeout.
WinUI doesn't have Toasts, but it does have the TeachingTip. in the future, WinUI is planning on building this auto-dismiss behavior into the TeachingTip itself, but we're impatient.
Use cases that would be good for this:
- A. Enable auto-elevation for a profile #8514 - When we open a tab in another elevated window, it might be nice to display a toast to the user "A new tab was created in an elevated window"
- B. As mentioned in Spec for Windows Terminal Window Management #8135: we'll need a little UI element for displaying the Window IDs/names. Maybe a window-level toast would work?
- C. Similar to the above, inspired by moveFocus to panel using number #5803, Add support for
focus-panesubcommand #5464, Support for navigating panes by MRU #8183: display a toast in each pane showing the Pane IDs - D. inspired by discussion in Implement ConEmu's OSC 9;9 to set the CWD #8330: in that PR, we'll fall back to the profile's
startingDirectoryif the provided directory doesn't exist. In that case, we could display a toast to the user as well. - E. Feature Request: Show terminal size when resizing the window Feature Request: Show terminal size when resizing the window #2833
- Maybe? This might not be the best example for a toast.
- F. Add support for OSC777 - send notification #14425 (comment) - display the notification as a Toast, instead of an OS-level notification
- Add an option to show notification when copying content #17561: We thought about it, but also these Toasts are FAR too heavy for as lightweight a thing as we need for that.
From the above, there are two kinds of scenarios where we want Toasts: control-level and window-level.
- A, B, D are all window-level. There's one Toast visible, at the window level. Changing tabs wouldn't hide this toast (this is important for D, where the toast would be fired as the new tab is opening, and we probably want the toast to persist in both the original tab and the tab that's created).
- C is a control-level toast. Each pane would display a toast. Changing tabs would hide these toasts.
I'm not prescribing any interactable UI in these toasts, but TeachingTips do allow buttons and other rich content.
I'm sure there are other things we could do too. This issue is so I don't lose track of the possible scenarios.
Other things:
- Something like "Unable to rename window. Another window with that name already exists."
Activity
DHowett commentedon Dec 16, 2020
Control level toasts also include the resize size indicator!
DHowett commentedon Dec 17, 2020
Backlog approved.
zadjii-msft commentedon Jan 20, 2021
Alright, so I tried to do this today. Here's what I learned:
TeachingTipis definitely focusable, or in the tab order, or something. So it's certainly possible for it to steal the focus from theTermControl.TabViewItem, not theTermControl. That's aggressively annoying.TeachingTip, and don't give it aTarget, it's always going to be placed relative to the XAML ROOT, not _whatever thing is the parent element of theTeachingTip. This is particularly painful because none of the placement options allow you to place it within the bounds of the target. They all want to be outside the target, on the side somewhere.PlacementMarginof-80, -80, -80, -80, which seemed to work alright in a XAML studio scratch page, but doesn't work well in the Terminal itself.-80, -80, -80, -80is obviously contrived. I should only need to set one of those to -80, right? But it's not clear if it'sToporBottomthat needs to be set.ShouldConstrainToRootBounds?TeachingTipssmaller? Like, "Pane 1" is not a whole lot of text.TeachingTipsjust dying immediately.TeachingTipswill reserve space for theTitleandSubtitle, even if one is null/empty. We probably only want one at a time.TeachingTip/Toast, so we can dismiss it properly at the end of the timer. The way I did that was with two classes:Toastwas the container for the Timer and the TeachingTip, and after the timeout, would hide the TeachingTip. It shouldn't be constructed on it's own though.Toasterwas the container for "Thing to create and ownToasts". It would be able toMakeToaston a given (optional) UI element, and would hold all theToasts it creates, then remove them when their timer expires.TerminalPagehad aToasterit could use to send toasts. It did not feel like a natural extension ofTeachingTip.My work is over in
dev/migrie/f/com.fabrikam.toaster. Feel free to check it out if interested.Add an action for identifying windows (#9523)
Replace the UWP file export with the shell32 one (#11365)