Skip to content
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

Fix wrong item template selection in CmdPal #9487

Merged
merged 4 commits into from
Mar 25, 2021

Conversation

Don-Vito
Copy link
Contributor

@Don-Vito Don-Vito commented Mar 13, 2021

PR Checklist

Detailed Description of the Pull Request / Additional comments

There seems to be a bug in WinUI (see microsoft/microsoft-ui-xaml#2121)
that results in heterogeneous ModernCollectionBasePanel configured
with DataTemplateSelector and virtualization enabled
to recycle a container even if its ContentTemplate is wrong.

I considered few options of handling this:

  • Disabling virtualization (by replacing item container template with
    some non-virtualizing panel (e.g., StackPanel, VirtualizingStackPanel
    with VirtualizationMode=Standard)
  • Replacing DataTemplateSelector approach with ChoosingItemContainer
    event handling approach, which allows you to manage the
    item container (ListViewItem) allocation process.

I have chosen the last one, as it should limit the amount of allocations,
and might allow optimizations in the future.

The solution introduces:

  • A container for ListViewItems in the form of a map of sets:
    • The key of this map is a data template (e.g., TabItemDataTemplate)
    • The value in the set is the container
  • ChoosingItemContainer event handler that looks for available
    item in the container or creates a new one
  • ContainerContentChanging event handler that returns the
    recycled item to the container

@ghost ghost added Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal. labels Mar 13, 2021
Copy link
Member

@zadjii-msft zadjii-msft left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well this is mental. But a good workaround! Thanks!

</DataTemplate>

<DataTemplate x:Key="NestedItemTemplate" x:DataType="local:FilteredCommand">
<Grid HorizontalAlignment="Stretch" ColumnSpacing="8" AutomationProperties.Name="{x:Bind Item.Name, Mode=OneWay}" AutomationProperties.AcceleratorKey="{x:Bind Item.KeyChordText, Mode=OneWay}">
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we losing the HelpText (More options) from x:Uid="CommandPalette_MoreOptions"

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah -- we gotta keep this. I'll block for the answer. 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit worried we're losing a couple things by leaving ListViewItem behind. Hmm. Can the ChoosingXyz event not return a ListViewItem?

Copy link
Contributor Author

@Don-Vito Don-Vito Mar 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ChoosingItemContainer chooses an item container 😄 or more precisely - SelectorItem, which is a parent for *ViewItem.

I mean I played with Narrator and it felt OK.. but probably I missed stuff (my mind was erased while debugging WinUI).

What do you believe will be broken? How can I test that? I probably won't be able to make ChoosingItemContainer return something else, but if you tell me what the concern is, I might find an answer 😊

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean I lost MoreOptions (I was not aware of it unfortunately). I guess I can try to fix this 😊 But are there additional concerns?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will fix this by binding the automation properties in the code behind, and resubmit. Sorry.

Copy link
Member

@DHowett DHowett Mar 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're getting to the things I hate about XAML. It's like... we did all this work to get away from manually setting up specific values in the codebehind or in the xaml document for specific types of items, right? It was good and clean and smart: the DataTemplate provided everything we needed for the data type. And here, we're forced to add detection to ChoosingItemContainer (sp) to set up the container correctly based on the data type. Something the data template should be able to handle. All because of a silly issue. 😄

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have expressed my distaste in the linked Xaml issue. Thanks for debugging through WinUI so much. 😀 It can be enough to drive a person mad.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, one last e-mail. It does not work if we add x:Uid="CommandPalette_MoreOptions" to the Grid?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it doesn't. There is no AutomationPeer for the grid. I am still wondering why the text is read correctly. Most probably due to the default automation peer on the internal text block.

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as mentioned

@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Mar 15, 2021
@Don-Vito Don-Vito marked this pull request as draft March 16, 2021 00:52
@Don-Vito Don-Vito marked this pull request as ready for review March 21, 2021 00:12
@Don-Vito Don-Vito requested a review from DHowett March 21, 2021 00:13
@Don-Vito
Copy link
Contributor Author

@DHowett - please re-review 😊 when you can. Currently main is quite broken without it!


if (dataTemplate == _itemTemplateSelector.NestedItemTemplate())
{
const auto helpText = winrt::box_value(RS_(L"CommandPalette_MoreOptions"));
Copy link
Member

@DHowett DHowett Mar 25, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just checking (and I will merge this before you reply! (unless you are quite fast!))

This is fine, and we never need to clear the Automation Property, because it is only ever applied to items that use the NestedItemTemplate template? And the cache stores them separately. Okay. I've talked myself into it.


</Grid>
</ListViewItem>
AutomationProperties.AcceleratorKey="{x:Bind Item.KeyChordText, Mode=OneWay}"/>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm surprised this binding actually works! It's on the parent ListViewItem, but that ListViewItem is never bound to the actual object in our code. Is this just something that ListView handles for us?

Copy link
Member

@DHowett DHowett left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm testing this out locally, but I expect to merge it!

@DHowett
Copy link
Member

DHowett commented Mar 25, 2021

As expected, it is perfect.

@DHowett
Copy link
Member

DHowett commented Mar 25, 2021

Thank you @Don-Vito. For both fixing this and putting up with my concerns ALL THE TIME

@DHowett DHowett added the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Mar 25, 2021
@DHowett DHowett merged commit e02d9a4 into microsoft:main Mar 25, 2021
@DHowett DHowett removed the zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. label Apr 2, 2021
DHowett pushed a commit that referenced this pull request Apr 2, 2021
There seems to be a bug in WinUI (see microsoft/microsoft-ui-xaml#2121)
that results in heterogeneous `ModernCollectionBasePanel`  configured
with `DataTemplateSelector` and virtualization enabled to recycle a
container even if its `ContentTemplate` is wrong.

I considered few options of handling this:
* Disabling virtualization (by replacing item container template with
  some non-virtualizing panel (e.g., `StackPanel`,
  `VirtualizingStackPanel` with `VirtualizationMode`=`Standard`)
* Replacing `DataTemplateSelector` approach with `ChoosingItemContainer`
  event handling approach, which allows you to manage the item container
  (`ListViewItem`) allocation process.

I have chosen the last one, as it should limit the amount of
allocations, and might allow optimizations in the future.

The solution introduces:
* A container for `ListViewItem`s in the form of a map of sets:
  * The key of this map is a data template (e.g., `TabItemDataTemplate`)
  * The value in the set is the container
* `ChoosingItemContainer` event handler that looks for available item in
  the container or creates a new one
* `ContainerContentChanging` event handler that returns the recycled
  item to the container

Closes #9288

(cherry picked from commit e02d9a4)
@zadjii-msft zadjii-msft added the zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes. label Apr 6, 2021
@DHowett DHowett removed the zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes. label Apr 13, 2021
@ghost
Copy link

ghost commented Apr 14, 2021

🎉Windows Terminal v1.7.1033.0 has been released which incorporates this pull request.:tada:

Handy links:

@ghost
Copy link

ghost commented Apr 14, 2021

🎉Windows Terminal Preview v1.8.1032.0 has been released which incorporates this pull request.:tada:

Handy links:

zadjii-msft added a commit that referenced this pull request Jun 10, 2024
Surprise surprise! we ran into an old friend:
* #9288
* #9487
* microsoft/microsoft-ui-xaml#2121

so uh, this is ded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-User Interface Issues pertaining to the user interface of the Console or Terminal Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-3 A description (P3) Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants