-
Notifications
You must be signed in to change notification settings - Fork 8.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace the KB Dialog with a InfoBar #8524
Replace the KB Dialog with a InfoBar #8524
Conversation
Couple of thoughts. Does the InfoBar follow the theme chosen for the profile/app - or does it pick Light or Dark theme based on the console's background colour's brightness so as to fit better? Does it use the default severity colours built into the control's template - or do you map the colours to the profile's equivalent colour? Green for Success |
It's a pretty standard Literally the only styling I've written for it is <mux:InfoBar x:Name="KeyboardWarningInfoBar"
IsClosable="True"
IsIconVisible="True"
IsOpen="False"
Severity="Warning"
Message="{x:Bind KeyboardServiceDisabledText, Mode=OneWay}"/> |
@@ -98,6 +98,7 @@ the MIT License. See LICENSE in the project root for license information. --> | |||
VerticalAlignment="Stretch" /> | |||
|
|||
<mux:InfoBar x:Name="KeyboardWarningInfoBar" | |||
x:Load="False" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You do unfortunately need to use the FindName
trick with Load; as written it will crash i think
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(this is because the member isn't populated until the control is loaded, but FindName loads it (instead of finding it. official API!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is really good to know. Just hit this in my own implementation haha.
The control can handle itself fine in terms of matching the App's RequestedTheme / The Theme set in Settings. I suppose what I was wondering is if it should match the UI or if it should match the Profile, in terms of colour. It seems to be in that between zone in that it could be part of the Tabs and Window Frame UI Zone, or it could be part of the Console area. If the InfoBar persists when switching tabs, then it makes sense to match the App. |
Yeah, so this one is app-affine and not terminal pane affine. In general, there isn’t a well-defined “warning” color in a terminal application. We get to choose red, or yellow, or green or whatever but the user can reassign those color indices to be whatever color they want. There’s no contract that index 1 must be red, nor that an application use index 1 for warnings or errors. It’s a neat idea, but I wouldn’t want to introduce too many dependencies on ill-defined things 😄 |
Cool - I was just adding some thoughts to the discussion (or was that opening a discussion) - either way it makes sense for it to be app level! |
(That said, I do like the idea. There has been some discussion in the .NET world and presumably the general CLI community about having something closer to semantic markup or more representative of application intent in terminal emulation. Not likely to to anywhere, but interesting to consider what a world is like where we give text meaning instead of just style!) |
Quite a departure from a "dumb" terminal churning through command codes... |
Eh, so is OSC 8 hyperlink support. 😄 There's a fine line, for sure. |
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
If that InfoBar has to be dismissed manually then it's not any better than a popup. Is still annoying to have it in my face every time the terminal starts. This might be acceptable for light users, but not for those using the terminal heavily. |
This changes the keyboard warning from a dialog to an `InfoBar`, which we just got in MUX 2.5. Some users were unhappy that we'd always display the dialog. We learned from the input team that this service _should_ always be enabled. We're also learing from users that they don't always want it enabled. We're working with the Input team to help us figure out how this service can be disabled _and the Terminal work just fine_. They're confident that it _shouldn't_. For 99% of our users, they're right. So we don't want to get rid of the dialog entirely, we want to understand how this is possible. While we wait, let's make the message less aggressive. This is instead of making a `iKnowWhatImDoingDisableTheKeyboardWarning` setting to disable the dialog. Props to @cornem for suggesting the less aggressive solution. ## Validation Steps Performed Tested manually, but by forcing the message to always display. Disabling the service requires two full reboots, and _ain't nobody got time for that_. Closes #8228 Closes #4448, for now (cherry picked from commit ff5b2b8)
🎉 Handy links: |
🎉 Handy links: |
This changes the keyboard warning from a dialog to an `InfoBar`, which we just got in MUX 2.5. Some users were unhappy that we'd always display the dialog. We learned from the input team that this service _should_ always be enabled. We're also learing from users that they don't always want it enabled. We're working with the Input team to help us figure out how this service can be disabled _and the Terminal work just fine_. They're confident that it _shouldn't_. For 99% of our users, they're right. So we don't want to get rid of the dialog entirely, we want to understand how this is possible. While we wait, let's make the message less aggressive. This is instead of making a `iKnowWhatImDoingDisableTheKeyboardWarning` setting to disable the dialog. Props to @cornem for suggesting the less aggressive solution. ## Validation Steps Performed Tested manually, but by forcing the message to always display. Disabling the service requires two full reboots, and _ain't nobody got time for that_. Closes microsoft#8228 Closes microsoft#4448, for now
This changes the keyboard warning from a dialog to an
InfoBar
, whichwe just got in MUX 2.5. Some users were unhappy that we'd always display
the dialog. We learned from the input team that this service should
always be enabled. We're also learing from users that they don't always
want it enabled.
We're working with the Input team to help us figure out how this service
can be disabled and the Terminal work just fine. They're confident
that it shouldn't. For 99% of our users, they're right. So we don't
want to get rid of the dialog entirely, we want to understand how this
is possible. While we wait, let's make the message less aggressive.
This is instead of making a
iKnowWhatImDoingDisableTheKeyboardWarning
setting to disable the dialog. Props to @cornem for suggesting the less
aggressive solution.
Validation Steps Performed
Tested manually, but by forcing the message to always display. Disabling
the service requires two full reboots, and ain't nobody got time for
that.
Closes #8228
Closes #4448, for now