These are chat archives for AvaloniaUI/Avalonia

Oct 2017
Oct 15 2017 14:15
Can #1087 be closed now?
Oct 15 2017 15:30
Hi, I usually compiled and used the project myself. For another project I thought i'd use the nuget package but that didn't work; because of the targets file in Avalonia.Skia.Linux.Natives , it looks in the wrong directory for the SkiaSharp libs. Am I doing something weird or is that a bug? I changed the locations (../.../SkiaSharp.1.57.1 vs ../../../SkiSharp/1.57.1) and all works as expected.
Jeremy Koritzinsky
Oct 15 2017 17:25
I think we need to update our Portable.Xaml submodule for that.
Nikita Tsukanov
Oct 15 2017 20:17
@tluyben our packages won't work with packages.config
We do not support the old SDK anymore
We also don't support Packet
Basically, we don't support anything that doesn't place packages to %USERPROFILE%\.nuget\{packagename}\{version}
Nikita Tsukanov
Oct 15 2017 22:45
@grokys @jkoritzinsky Since Portable.Xaml doesn't require markup extensions to derive from MarkupExtension
Can we have our own base class for that?
So we won't have people to depend on Portable.Xaml when writing their own extensions
Right now it's not much of an issue, but since XAML parsing engine is likely to change again (we might get our own, create XAML compiler, whatever), we need something to keep backward compatibility
Jeremy Koritzinsky
Oct 15 2017 22:50
@kekekeks Will Portable.Xaml correctly pass the serviceProvider/xaml context to a provide value method if we do that? If so, I’m all for it.
Nikita Tsukanov
Oct 15 2017 22:51
No idea, it might require some patches
But I don't want us to depend on Portable.Xaml in our public API
Jeremy Koritzinsky
Oct 15 2017 22:53
I get that. I’d like us to get to the point where Avalonia.Markup.Xaml doesn’t have a dependency on a specific Xaml framework and then have a support package for the Portable.Xaml parser, but that’s just my idea.
I think we can go for this if it’s possible, but we should hold off until after beta 1.