These are chat archives for AvaloniaUI/Avalonia

15th
Aug 2017
Jeremy Koritzinsky
@jkoritzinsky
Aug 15 2017 00:48
@kekekeks the skia-merge branch is successfully building and testing skia, but is failing on Cairo for some reason. Any ideas?
danwalmsley
@danwalmsley
Aug 15 2017 07:05
Cairo is behind, things like corner radius are not implemented, perhaps its failing tests like these?
Matthijs ter Woord
@mterwoord
Aug 15 2017 08:38
regarding move to .net standard 2.0
are you guys on 1.x now?
Wiesław Šoltés
@wieslawsoltes
Aug 15 2017 09:14
1.3
Matthijs ter Woord
@mterwoord
Aug 15 2017 10:12
i think moving up shouldn't be much work
Steven Kirk
@grokys
Aug 15 2017 10:45
@jkoritzinsky i think the line render tests weren't included in the cairo render tests previously
you just need to skip them for cairo
Mark Junker
@fubar-coder
Aug 15 2017 12:26
@mterwoord Why would it be necessary to upgrade the libraries to 2.0, because 2.0 should be able to use the 1.3 libraries.
Nikita Tsukanov
@kekekeks
Aug 15 2017 12:27
We need 2.0 anyway
For P/Invoke-related stuff like ICustomMarshaler
Johan Larsson
@JohanLarsson
Aug 15 2017 12:27
Are there any reasons to keep standard version low?
More compatible devices?
Nikita Tsukanov
@kekekeks
Aug 15 2017 12:27
If you want to support .NET 4.5.1 for some reason
Johan Larsson
@JohanLarsson
Aug 15 2017 12:28
ah, ok, that is very valid
Nikita Tsukanov
@kekekeks
Aug 15 2017 12:29
I just don't see any good reason to support it
.NET 4.6.1 is compatible with the same set of windows versions
And for everything else we have .NET Core and Mono
Mark Junker
@fubar-coder
Aug 15 2017 12:32
It's good that the new csproj format allows multiple target frameworks 😊
Matthijs ter Woord
@mterwoord
Aug 15 2017 12:40
@fubar-coder i'm not suggesting the move, just saying it shouldn't be much work
i think targetting 2.0 is a good base point
Matthijs ter Woord
@mterwoord
Aug 15 2017 12:48
as avalonia will probably be prerelease a few more weeks (no harm intended..), i'd say pick a version the main devs can live with (and that's reasonalbe)
to me, targetting 2.0 sounds like a good starting
Nikita Tsukanov
@kekekeks
Aug 15 2017 13:44

pick a version the main devs can live with

Yep, we should have stayed on PCL and VS2015 for a year or so

That stack was something that we could live with
Matthijs ter Woord
@mterwoord
Aug 15 2017 13:48
@kekekeks at this moment (or coming weeks?...) i think the way to go for avalonia is net stndard/core.. how bad the tooling may be....
:)
past months, staying would probably have been best..
Nikita Tsukanov
@kekekeks
Aug 15 2017 13:50
The thing is that we could have netstandard1.3 as a target
using old SDK
just as fine
It won't be compatible with VS2017
But there actually was no need in that
Our rationale was "meh, we'd have to migrate our projects twice, let's wait until VS2017 release and use the new SDK"
csproj+project.json combo from old UWP SDK
was working just fine
No weird errors, no crashes, no freezes
Steven Kirk
@grokys
Aug 15 2017 13:55
VS2015+PCL was heaven
apart from not having TypeConverters
Nikita Tsukanov
@kekekeks
Aug 15 2017 13:55
VS2015 with .NET Core tooling preview was stable
and we could have TypeConverter and other stuff from netstandard<=1.5 that way
The only issue was inability to target netstandard1.6 with csproj project format
Steven Kirk
@grokys
Aug 15 2017 13:56
maybe things will be more stable if we manage to convert all projects to .netstandard2 + new csproj
Nikita Tsukanov
@kekekeks
Aug 15 2017 13:57
I never had any issues during GTK3 backend development
Steven Kirk
@grokys
Aug 15 2017 13:57
i think the fact we were using a mix caused a lot of problems
Nikita Tsukanov
@kekekeks
Aug 15 2017 13:57
which was targeting netstandard1.3 right from the start
nope, problems came with VS2017
We could have migrated everything to netstandard1.3 and stay on VS2015
Nobody had known what kind of disaster was waiting for us
Steven Kirk
@grokys
Aug 15 2017 13:59
yeah, unfortunately not :(
2017.3 does seem to be better though
although if you change a project from netstandard1.3 to netstandard2.0 in the IDE it still hangs for 2.5 minutes
i think at this point the problems are with nuget
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:01
tbh, when you change target framework in VS2015 it will freeze for a while
and then you have to reinstall everty nuget package
Steven Kirk
@grokys
Aug 15 2017 14:01
yeah
it's never been a good experience. though i don't think the hang was 2.5 minutes before
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:02
20-30 seconds at most
Steven Kirk
@grokys
Aug 15 2017 14:03
i made a quick attempt at moving to netstandard2.0 last night and don't think it will be too difficult, but i want to wait for #1077 before i try properly
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:04
we also need to wait for appveyor
they are still on VS2017.2
Matthijs ter Woord
@mterwoord
Aug 15 2017 14:14
can't you just make a script to install .net sdk 2?
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:48
Oh, that's easy
The problem is that
each time we change anything in build
add package, move projects or, even worse, update some SDK-related tooling
We are getting tons of weird errors
And some of them you can't even google
And even if one gets it to build on the local machine
The environment on AppVeyor is just a little bit different
And it fails there with completely different set of errors
Steven Kirk
@grokys
Aug 15 2017 14:53
btw looks like there are still problems mising old and new csproj files dotnet/project-system#2712
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:54
SleepEx
sweet
Steven Kirk
@grokys
Aug 15 2017 14:55
do we need to stay on the old csprojs just for xamarin?
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:56
I think so
If we could move libraries to the new project format
Steven Kirk
@grokys
Aug 15 2017 14:56
yeah, they're nearly all there
Nikita Tsukanov
@kekekeks
Aug 15 2017 14:56
We'd be able just unload code with samples
Nikita Tsukanov
@kekekeks
Aug 15 2017 15:06
I wish we could make a switch for WPF-based projects too
(ones with integration and previewer)
Well, previewer doesn't depend on anything, so it's not really "mixing project types"
We also should burn GTK#/Cairo backend, I think
Once MonoMac-based one is merged
just wow
Steven Kirk
@grokys
Aug 15 2017 15:26
yep definitely :fire: cairo/gtk
danwalmsley
@danwalmsley
Aug 15 2017 15:46
@grokys it seems opacity right now is working both forward and backward !!! what do I mean by that...
this...
image.png
can you see the button icons (toolbar style buttons)
they should be completely obscured by the gray filled grid (which packages text is ontop of)
as soon as anything gets an opacity < 1
its seems to be visible in any layer
rather than allowing layers behind it to be visible
does that make sense?
when the toolbar buttons have opacity = 1
you cant see them when this dialog is up
Nikita Tsukanov
@kekekeks
Aug 15 2017 17:08

working both forward and backward

Looks like integer overflow

Might be a bug in Skia backend actually
Steven Kirk
@grokys
Aug 15 2017 17:45
Yeah, is this on skia? From what I remember opacity on the skia backend is a bit of a hack
danwalmsley
@danwalmsley
Aug 15 2017 17:56
Skia yes
Not tried direct2d
Btw how much work is involved in getting scengraph work running on gtk3 backend?
Jeremy Koritzinsky
@jkoritzinsky
Aug 15 2017 18:22
Almost done with the skia-merge PR. Just fighting with Cake now.
danwalmsley
@danwalmsley
Aug 15 2017 19:30
Just out of interest what's the skia merge about?
Merge multiple projects into 1
Nikita Tsukanov
@kekekeks
Aug 15 2017 19:43
It's about overcoming the issues brought by render test projects being migrated to the new SDK
Jeremy Koritzinsky
@jkoritzinsky
Aug 15 2017 19:58
It's in master!
Travis is running extremely slow today