You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi!
I would like to ask can you consider naming of some properties to match their more common use cases in WPF.
An example for this is Items vs ItemsSource.
In my humble opinion, it would make more sense to have your Items property named ItemsSource simply because the way one uses it in binding more closely resembles how one uses ItemsSource in WPF. Normalizations like this to existing XAML standards might make it easier for people to port apps from WPF to Avalonia, especially with the prospect of automating such transitions where possible (and it seems to be possible for a lot of layout related stuff).
I am unaware if there is a specific reason why this isn't the case and if it was brought up somewhere, can you please direct me to it so I can read?
Having only a single Items property is intentional in Avalonia. It was originally considered somewhat confusing that there are two properties for this in WPF. The docs really need to expand on this though: https://docs.avaloniaui.net/misc/wpf/itemscontrol
That said, I've seen other discussions where this is likely going to change:
Yeah this is something I decided to do back at the beginning of the project when I didn't expect anyone to be using it ;)
In hindsight it was a mistake, not just because of porting issues, but also for performance reasons.
Unfortunately changing the name of the property at this point would break pretty much everyone who uses Avalonia. One solution might be to add ItemsSource and make it do exactly the same as Items, but I'm not sure if that might cause other problems. If we're going to do this we should probably decide to do it for the next major version this year.
If we're going to do this we should probably decide to do it for the next major version this year.
If that means "do it now or never" then my vote is change it now. I think there are enough cases you have discovered to justify it. It also helps the compatibility story as mentioned here.
If it's hurting performance, then I'm...hesitantly in agreement with @robloo on this. Not going to pretend I see the whole picture though...but does anyone, really?
I think even though its called avalonia if they made the same name of the properties then people wouldn't have to ask so many new questions about stuff.
@kekekeks asked me in chat "how exactly is the Items property hurting performance?" and I think it'd be a good idea to explain here:
In WPF, there are two items container properties, with only one of them being settable at any time:
Items which contains a list of inline item containers
ItemsSource which points to a collection from which item containers will be created
In Avalonia the Items collection can be both: it can contain both inline item containers and items from which item containers will be created.
The thing that hurts performance is the fact that inline items need to be part of the logical tree even before the ItemsControl is added to the visual tree. To give an example:
When the "Empty" tab is open here, the ListBox (and by extension ListBoxItem) isn't part of the visual tree, but the ListBoxItem still needs to be visible in the logical tree.
If we had a separate Items and ItemsSource property this wouldn't be necessary: anything added to Items would get immediately added to the logical tree, anything added to ItemsSource would only cause a control to be added to the logical tree when a container gets created for the item.
Activity
robloo commentedon Feb 8, 2022
Having only a single
Itemsproperty is intentional in Avalonia. It was originally considered somewhat confusing that there are two properties for this in WPF. The docs really need to expand on this though: https://docs.avaloniaui.net/misc/wpf/itemscontrolThat said, I've seen other discussions where this is likely going to change:
grokys commentedon Feb 8, 2022
Yeah this is something I decided to do back at the beginning of the project when I didn't expect anyone to be using it ;)
In hindsight it was a mistake, not just because of porting issues, but also for performance reasons.
Unfortunately changing the name of the property at this point would break pretty much everyone who uses Avalonia. One solution might be to add
ItemsSourceand make it do exactly the same asItems, but I'm not sure if that might cause other problems. If we're going to do this we should probably decide to do it for the next major version this year.robloo commentedon Feb 8, 2022
If that means "do it now or never" then my vote is change it now. I think there are enough cases you have discovered to justify it. It also helps the compatibility story as mentioned here.
Splitwirez commentedon Feb 11, 2022
If it's hurting performance, then I'm...hesitantly in agreement with @robloo on this. Not going to pretend I see the whole picture though...but does anyone, really?
myplaths commentedon Mar 17, 2022
I think even though its called avalonia if they made the same name of the properties then people wouldn't have to ask so many new questions about stuff.
grokys commentedon Nov 22, 2022
@kekekeks asked me in chat "how exactly is the
Itemsproperty hurting performance?" and I think it'd be a good idea to explain here:In WPF, there are two items container properties, with only one of them being settable at any time:
Itemswhich contains a list of inline item containersItemsSourcewhich points to a collection from which item containers will be createdIn Avalonia the
Itemscollection can be both: it can contain both inline item containers and items from which item containers will be created.The thing that hurts performance is the fact that inline items need to be part of the logical tree even before the
ItemsControlis added to the visual tree. To give an example:When the "Empty" tab is open here, the
ListBox(and by extensionListBoxItem) isn't part of the visual tree, but theListBoxItemstill needs to be visible in the logical tree.What this means is that every time an item is added to
ItemsControl.Itemswe need to check if the item is a control and if so add it to the logical tree.If we had a separate
ItemsandItemsSourceproperty this wouldn't be necessary: anything added toItemswould get immediately added to the logical tree, anything added toItemsSourcewould only cause a control to be added to the logical tree when a container gets created for the item.grokys commentedon Feb 16, 2023
I've looked into doing this, but I think we need to do #9944 first, as that's going to affect how this is implemented.