Added ItemsControl.ItemsSource.

[grokys]

What does the pull request do?

Adds ItemsControl.ItemsSource with a similar behavior to WPF/UWP:

• ItemsControl.Items is now of type IList so that the collection can be modified using Add/Remove etc
• When ItemsControl.ItemsSource is set, Items goes into read-only mode and functions as a view over the items source
• Because ItemsSource is not initialized with an empty collection, it can be a styled property

There is one main difference from WPF/UWP, added for backwards compatibility:

• The Items property can still be bound and set (though this is deprecated). In this case, the items collection can still be accessed via the (pre-existing) ItemsView property. For this reason Items is of type IList and not ItemCollection

To allow both Items and ItemsSource to be bound, I had to add support for multiple InheritDataTypeFromItems attributes to be applied to a property. In this case that won't be a problem because only one can be set, though I'm not sure if it could could cause confusion in future?

Doesn't correct usages of Items to ItemsSource except where necessary (i.e. IEnumerable was being assigned to Items). Done in a separate PR as it's a big noisy change

Doesn't change the name of the Items property or add an ItemsSource to other ItemsControl-like controls. That can also be done later.

Depends on #10589

Fixed issues

Fixes #7553
Fixes #10509

[grokys]

Ready for review, I think.

[avaloniaui-team]

You can test this PR using the following package version. 11.0.999-cibuild0031738-beta. (feed url: https://pkgs.dev.azure.com/AvaloniaUI/AvaloniaUI/_packaging/avalonia-all/nuget/v3/index.json) [PRBUILDID]

[hez2010]

To allow both Items and ItemsSource to be bound, I had to add support for multiple InheritDataTypeFromItems attributes to be applied to a property. In this case that won't be a problem because only one can be set, though I'm not sure if it could could cause confusion in future?

How about breaking it and dropping the support for binding to Items, then change the type of Items to ItemCollection?
We already have plenty of breaking changes in v11.0 and need both control and app authors to migrate, why not another breaking change when we still can? It won't be a problem if we document it properly.
Otherwise, if we ship it as is, we will lose the chance to make breaking changes around here.

[Mrxx99]

How about breaking it and dropping the support for binding to Items, then change the type of Items to ItemCollection?

Together with a specialized error message telling to bind to ItemsSource when trying to bind to Items instead of some cryptic or general error, that sounds like a good idea. Not showing a specific error would make it confusing as everyone first learned to use Items in Avalonia.

[amwx]

I agree with above. I think changing the setter to throw an error that says change to ItemsSource is the best. Then in the future, the setter and DirectProperty can be removed without really being a breaking change. Since most binding usages are in Xaml, how noticeable is it that binding (or setting Items) is obsolete. I don't know about Rider, but in VS I know we don't tag obsolete warnings in the xaml document. VS also doesn't show all errors/warnings/messages by default unless you do a full rebuild, so unless you pay attention to the command line while building or open all files, this isn't 100% transparent.

[grokys]

The feedback we've been getting from customers is that port a large project from 0.10.x to 11.x results in an almost overwhelming number of compile errors. Given that Items is a very common property, the idea was at least they could get up-and-running using Items as previously, and then migrate to using ItemsSource afterwards.

I'm 100% open to making Items read-only, but given that the downside should be very minor, I'm not sure that we should.

[timunie]

I'm 100% open to making Items read-only, but given that the downside should be very minor, I'm not sure that we should.

How painful would it be to revert this change if the complaints are getting too much?

[hez2010]

The feedback we've been getting from customers is that port a large project from 0.10.x to 11.x results in an almost overwhelming number of compile errors.

Unlike other breaking changes, this one can be fixed easily with a simple find-and-replace.

[grokys]

I've spoken to one of the customers who gave us that feedback and they feel that this wouldn't be a particularly bad breaking change. Given that, and the feedback here so I think we'll be ok to remove the Items setter 🎉

We should do it in a subsequent PR though I feel, so it can potentially be reverted if we get more feedback.

[danwalmsley]

LGTM: Agreed YOLO to get this tested