* TabItem.TabStripPlacemenet should be correctly set
* fix: TabItem.TabStripPlacemenet should be correctly set
* move TabItemStripPlacement assignment to PrepareContainerForItemOverride
* remove excessive UpdateTabStripPlacement call on TabStripPlacementProperty.Changed
This was signalled for removal in #9553, but I was hesitant to do it because it will be in use by a lot of code in order to override `StyleKey`. Instead of removing it, deprecate it and provide a virtual `StyledElement.StyleKeyOverride` property as the supported way of overriding a control's style key.
`ItemsControl` now works more like WPF, in that there are separate `Items` and `ItemsSource` properties. For backwards compatibility `Items` can still be set, though the setter is deprecated. `Items` needed to be changed from `IEnumerable` to `IList` though.
- Removes the `IStyler` service and the `Styler` implementation
- Moves the logic for applying styles and control themes into `StyledElement`
- Removes the style `TryAttach` method from the public API
- Removes style caching for now - this will need to be added back
When a `TabItem` was created a binding was being set up to the owner `TabControl` but that binding was never being freed.
Ideally we'd be setting these properties in XAML rather than hardcoding them in the generator but that would be a breaking change for everyone who re-templated `TabControl`.
As a second-best option what we'd do is set up a `$parent` binding in the generator but this isn't available in Avalonia.Controls so had to implement a quick observable which watches for a parent `TabControl` and subscribes to it.
- Don't use Rx in the styling system. Instead introduces `IStyleActivator` which is like an `IObservable<bool>`-lite in order to cut down on allocations.
- #nullable enable on touched files
And implement the functionality in the content controls themselves. `ContentControlMixin` was too complex and even with its complexity had bugs (such as in #2821). By moving the functionality to the content controls there is some repeated code but it's much more straightforward.
`ContentControlMixin` implements a number of behaviors related to logical children that controls that have a `ContentPresenter` need in order to function correctly.
Also renamed `PART_Content` to `PART_SelectedContentHost` to match WPF
Fixes#2191
Added an `IDataTemplateHost` interface with a `IsDataTemplatesInitialized` property to prevent the need for allocating empty `DataTemplates` collections for many controls.
Make the untyped ItemContainerGenerator create `ContentPresenter`
containers when the data isn't a control. This is required for correct
binding to `DataContext` in a data template.
...during ApplyTemplate. This was so that ItemsControls could their find
ItemsPresenters nested in other templated controls. Instead use
IItemsPresenterHost to make the presenter register itself with its
TemplatedParent.
Usually controls are only registered with their name scope when they get
added to a rooted visual tree, but this causes problems for tests, and
would mean the templated control wouldn't work if the client called
ApplyTemplate themselves before the control is added to the visual tree.
Work around this by explicitly registering template controls with the
name scope when the template is applied.
To allow this, we need to allow controls to be registered with a name
scope multiple times.
Benedikt Stebner
pavelovcharov
Julien Lebosquain
Steven Kirk
Max Katz
Tom Edwards
Steven Kirk
Giuseppe Lippolis
Nikita Tsukanov
Deadpikle
Benedikt Schroeder
Jumar Macato