`ExpressionNode`s were always single-subscriber and making them use `IObservable<>` meant that we had to have extra allocations in order to return `IDisposable`s. Instead of using `IObservable` use a simpler `Subscribe`/`Unsubscribe` pattern. This saves a bunch more memory.
I started fixing #1559 and decided to rework our `TypeConverter` infrastructure a bit.
This PR renames `AvaloniaDefaultTypeConverters` to `AvaloniaTypeConverters` and allow registration of 3rd party converters here.
`AvaloniaTypeConverters` improves upon the type converter functionality in the BCL by providing the followinng extra functionality:
- Allow registering non-constructed generic types (such as `AvaloniaList<>`) - `AvaloniaTypeConverters` will do the sensible thing and create an `AvaloniaListConverter<T>` with the correct type
- If no type converter is provided, look for a a static `Parse(string)` method which can be used to create an implicit type converter
This allows us to remove a bunch of `TypeConverter`s which just called the relevant `Parse` method.
Fixes#1559
Makes Avalonia more like other XAML frameworks, in that any avalonia property can now be set anywhere. The XAML parser however will only allow you to set registered properties.
Instead of using `Observable.ObserveOn` in bindings, interface with `Dispatcher.UIThread` to schedule binding notifications on the UI thread. This saves a significant amount of memory.
Previously it wasn't clear which constructor on `InstancedBinding` must be called for a particular binding mode. Refactored the constructors:
- We now have a single public ctor which takes an `ISubject`, as a subject can be used for all binding modes.
- Instanced bindings with other sources such as single values and `IObservables` are now constructed via static methods which only allow the correct sources for that binding mode
To do this needed to change behavior a little in that now binding errors update the target. Previously in the case of a binding error at the first node in the binding chain, we were converting the `BindingNotification` to `UnsetValue` which had the effect of updating the target value. Now we're passing the `BindingNotification` back, we need to make sure this happens. I believe this is the right thing to do as the behavior should be the same no matter where in the binding chain the error occurs. Data validation errors continue to not update the target.
1. Fixed some tests to expect `BindingNotification`s to be returned on a broken binding chain.
2. Changed logging of `BindingNotification`s - log at `Warning` level (instead of `Error`) except when the binding chain is broken at the root, in which case log at `Information` level. Do this to prevent flooding the output window when initializing.
Steven Kirk
Jeremy Koritzinsky
Steven Kirk
José Pedro
Nikita Tsukanov
Wiesław Šoltés