Conversation
Probably just going to remove this entirely tbh
|
@carlos-zamora EDIT:
EDIT 2: yep that worked |
|
My only feedback is to change the page name to Actions and then scoot the right column closer to the left a bit. Otherwise, this is fantastic. :) |
carlos-zamora
left a comment
There was a problem hiding this comment.
I have a few design issues that I'm conflicted with because of a short release window:
- nested commands should pop up in a hierarchical view
- if a command doesn't have a name, it won't appear in the list, right?
We've basically created a command palette copy in the settings UI. But in that case, what value does it add? Why doesn't the user just open the command palette in another tab and get nested commands for free?
I'm not approving because I'm genuinely conflicted by the value this adds. But I'm not going to block it because it seems to be what we want. I'll circle back to how I feel about this in the afternoon.
| <data name="Globals_KeybindingsLink.Content" xml:space="preserve"> | ||
| <value>Open JSON settings</value> | ||
| </data> |
There was a problem hiding this comment.
nit: maybe to try and reduce loc burden, could we just reuse the Nav_OpenJson/Content?
| <data name="Nav_Actions.Content" xml:space="preserve"> | ||
| <value>Keybindings</value> | ||
| </data> |
There was a problem hiding this comment.
According to this design doc, I think it's supposed to be named "Keyboard". But I feel like we changed it at some point. @cinnamon-msft can you confirm what the name should be?
There was a problem hiding this comment.
I'm torn on this now. I like Keyboard because it clearly shows the user where to find key bindings. However, our JSON uses Actions, so if someone wanted to edit their keys, would they know they'd have to edit the Actions array?
There was a problem hiding this comment.
Okay I'm going with Actions for now. The later in the day we get, the harder it will be to change again
| <TextBlock x:Uid="Globals_KeybindingsDisclaimer" | ||
| Style="{StaticResource DisclaimerStyle}"/> |
There was a problem hiding this comment.
(not @zadjii-msft's fault, but still relevant) This text block is not read by a screen reader (same with the disclaimer in base layer). I'll file a separate issue to track this one.
There was a problem hiding this comment.
This is going to be important for us to fix before any settings UI goes stable. Why are they not read?
There was a problem hiding this comment.
Moved to:
"Disclaimer" text boxes are not read in narrator #9255
|
|
||
| <ListView HorizontalAlignment="Stretch" | ||
| VerticalAlignment="Stretch" | ||
| SelectionMode="Single" |
There was a problem hiding this comment.
| SelectionMode="Single" | |
| SelectionMode="None" | |
| IsItemClickEnabled="False" |
Should we make it so that you can't interact with this? There's no reason for a user to select entries.
| SelectionMode="Single" | ||
| CanReorderItems="False" | ||
| AllowDrop="False" | ||
| ItemsSource="{x:Bind FilteredActions}" |
There was a problem hiding this comment.
| ItemsSource="{x:Bind FilteredActions}" | |
| ItemsSource="{x:Bind FilteredActions, Mode="OneWay"}" |
We should bind this OneWay. This may have caused some mayhem for you in trying to figure out why it didn't repopulate?
| { | ||
| runtimeclass ActionsPageNavigationState | ||
| { | ||
| Microsoft.Terminal.Settings.Model.CascadiaSettings Settings; |
There was a problem hiding this comment.
It seems like we only need GlobalAppSettings to get access to the list of commands. We should pass that in instead of the whole settings object.
There was a problem hiding this comment.
Sure, this was me being quick and dirty
There was a problem hiding this comment.
I suspect we will eventually need the whole thing. Just like Profiles needs Color Schemes.
what we really need is a viewmodel.
| looks quite redundant --> | ||
| <ContentPresenter x:Uid="Globals_Keybindings" Margin="0"> | ||
|
|
||
| <ListView HorizontalAlignment="Stretch" |
There was a problem hiding this comment.
I feel like we should have a header for each column here. But that's so much extra work for a small release window. Plus additional loc burden.
carlos-zamora
left a comment
There was a problem hiding this comment.
Ok. Sat down and thought about this more. I think what we have here is great for WT Preview. I'd like for it to get some kind of polish over the next month before it hits stable. But we'll just need some community feedback.
We'll also just have to have a conversation on how we want to transition from this read-only view to the actual one. I'm starting to think of some ideas for what that'll look like, but we really need @cinnamon-msft to fully design that out.
The point of this page is to quickly display a list of all the keybindings. Not of all the actions/commands. Not to expose the structure of the command palette. I'm not aware of anyone who's got a key bound to a nested command - there certainly aren't any bound by default. I'm willing to accept the bug for now that "nested actions with a key bound don't show up in the list of keybindings". (probably easy to fix now tbh...)
Correct. There's few and far between commands that don't have a generated name - usually that's due to parameters not being valid. I'll be shocked if someone reports "but muh command with a null name isn't displayed there". This is an artifact of me using the
Because already, nobody knows about the command palette. That's pretty consistently something I mention and people go "oh, that's neat, didn't know about that". The point here is 99% to just say "these are the current keybindings, you can edit them in the file", rather than have people ask how they change their keybindings with the settings UI. The target audience here is the user who knows 10% about the terminal, who might not even know the Terminal has remappable keys. I'm guessing people that already know to go to the file to change their keybindings are in the 50% range. People who are actively using I'm 100% okay throwing this out when the real UI lands. This is supposed to be throw-away code. |
|
Before adding icons consider that 0 of our built in actions have icons. I’d rather pass on additional complexity |
| String KeyChordText; | ||
|
|
||
| String Icon; | ||
| String IconPath; |
There was a problem hiding this comment.
but but but iuts' not a path
so sad about this :|
There was a problem hiding this comment.
I'd really really love for this to not be totally insane.
IconSource? idk. When I get more time, I'm gonna set up a simple repro for the WinUI team to tell me exactly wtf is going on here.
| { | ||
| runtimeclass ActionsPageNavigationState | ||
| { | ||
| Microsoft.Terminal.Settings.Model.CascadiaSettings Settings; |
There was a problem hiding this comment.
I suspect we will eventually need the whole thing. Just like Profiles needs Color Schemes.
what we really need is a viewmodel.
| <TextBlock x:Uid="Globals_KeybindingsDisclaimer" | ||
| Style="{StaticResource DisclaimerStyle}"/> |
There was a problem hiding this comment.
This is going to be important for us to fix before any settings UI goes stable. Why are they not read?
src/cascadia/TerminalSettingsEditor/Resources/en-US/Resources.resw
Outdated
Show resolved
Hide resolved
|
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 (
|
|
🎉 Handy links: |

This was the only thing blocking me from signing off on #9224 in 1.7.
! CHANGE WARNING !
☺️
If we bind to
T.S.M.Commands in XAML, then the compiler gets veryangry at us. It generates two different versions of
GetReferenceTypeMember_IconinXamlTypeInfo.g.cpp. Presumablybecause there's an Icon on a NavViewItem and an Icon on a Command. We
don't really know why. Fortunately, the fix is "rename Command::Icon" to
"Command::IconPath". It's dumb, but it works. Thanks for the help with
that one Carlos
Unblocks #9224