The WPF equivalent (`Style`) is in `FrameworkElement` so it would make sense. Will also make stuff a lot easier and removes the need for an `IThemed` interface.
* Merge core libraries.
Everything below `Avalonia.Controls` into `Avalonia.Base`.
* Move new files to correct place.
* Removed unused dirs/projects,
* Removed outdated references from theme assemblies.
* Merge unit tests to match new assembly layout.
* Fixup test namespaces.
* Make directory match namespace.
* Move files to match namespace.
* Move files to match namespace.
* Fix up incorrect namespace.
`Avalonia.Visuals.Media.Imaging` -> `Avalonia.Media.Imaging`.
* Fix resource URL.
* Removed outdated dependencies.
* Added missing project reference.
* Update test namespaces.
* Fix merge error.
* Fix merge errors.
* Fix bad merge in WindowsInteropTest.csproj.
* Fix up merge errors in csprojs.
* Remove merged tests from nuke.
* Fix up namespace.
* Fix compile error.
* Fix failing tests.
Now that more unit tests are present in Avalonia.Base.UnitTests, general `AvaloniaObject` properties are getting registered. Ignore those.
Co-authored-by: Jumar Macato <16554748+jmacato@users.noreply.github.com>
Instead of each control listening to its parent `ResourcesChanged` event, use the logical tree to propagate `ResourcesChanged` events:
- When attaching to the logical tree, piggyback on the `AttachedToLogicalTree` traversal
- At other times, propagate by calling `NotifyResourcesChanged`
Split resource nodes into two types:
- `IResourceHost` represents controls and `Application`
- `IResourceProvider` represents resource dictionaries and styles, these are owned by `IResourceHost`s
Dynamic resources are now always resolved from an `IResourceHost`: if an `IResourceProvider` doesn't have a host then a dynamic resource in the resource provider will not be resolved. Resource providers no longer have a `ResourcesChanged` event, instead they notify their `IResourceHost` owner of a resource change by calling the `NotifyHostedResourcesChanged` method.
In the case of #3708, the sanity check fails because the parent call to `SetParent` hasn't yet completed - it's the setting of `InheritanceParent` on the parent that causes the child to get attached.
- 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
- 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
The root of our logical tree is denoted by `IStyleRoot` for historical reasons: before #1594, styling was defined in `Avalonia.Styling` but the logical tree was defined in `Avalonia.Controls`. The styling system needed a root but because it was lower-level than the logical tree it had to define its own root type which was then repurposed for use by the logical tree.
Since #1594 the logical tree is defined in `Avalonia.Styling` as well so we might as well call `IStyleRoot` what it is: the logical tree root.
- When detaching set `Parent` to `null` before raising the `DetachedFromLogicalTree` event
- To do this, we need to store the logical root in the control so that e.g. a child control can be detached in a `DetachedFromLogicalTree` handler
- Add `Source` and `Parent` properties to `LogicalTreeAttachmentEventArgs` to give more context on what caused the attachment/detachment
It was only needed for pseudoclasses. Move pseudoclass registration to an engine that doesn't require `AvaloniaProperty.Initialized`, implemented in `PseudoclassEngine`.
`IResourceDictionary` was defined as an `IDictionary<object, object>` but in various places we only accepted a `string` as the resource key. Fix this inconsistency and always use `object` as a resource key.
Fixes#2456
Steven Kirk
Steven Kirk
Max Katz
Dariusz Komosinski
Nikita Tsukanov