These are chat archives for AvaloniaUI/Avalonia

14th
May 2016
Steven Kirk
@grokys
May 14 2016 08:14
@kekekeks sorry was a dinner last night
BTW, @grokys , RegisterServices should be called by AppBuilder
Ok, makes sense
There is also some weird condition in which Avalonia.Layout.UnitTests.LayoutManagerTests.Invalidating_Child_Should_Remeasure_Parent occasionly failes
could you add an issue when it shows up again? i've not seen this
I think that AppBuilder branch could be merged
:+1:
like @ImaBrokeDude_twitter i'm also wondering if there's not a way we can handle .dlls without .exes. what if you're creating a .dll of controls for example. you'll probably have a test .exe in the solution, true, but it feels like there should be a way to handle it?
Steven Kirk
@grokys
May 14 2016 08:20
not a big deal - i'll be happy just to get the designer working for the most common situations right now
Steven Kirk
@grokys
May 14 2016 09:41
BTW, why did we extracted designer support to a separate assembly?
not sure - i haven't really been involved in that stuff
@jkoritzinsky did it - what were the reasons for that, do you remember?
Steven Kirk
@grokys
May 14 2016 10:20
@kekekeks merged appbuilder-avalonia to master
Nikita Tsukanov
@kekekeks
May 14 2016 10:47
project.json RIP
Nikita Tsukanov
@kekekeks
May 14 2016 11:02

could you add an issue when it shows up again? i've not seen this

I've got that test failed with "Actual: (0,0), Expected: (100,100)" but couldn't reproduce it

danwalmsley
@danwalmsley
May 14 2016 11:40
I don'tsee why designer doesn'tjust provide its own avalonia.win32 dll?
Nikita Tsukanov
@kekekeks
May 14 2016 11:41
The problem isn't with providing dll
The problem is with locating one with correct version
Basically, you have your PCL with only PCL references in output directory
Where to look for that dll with platform support?
You also need to somehow locate App class
Which might not be in said PCL
danwalmsley
@danwalmsley
May 14 2016 11:43
It should be in one of the assemblies that the pcl references shouldn't it?
Nikita Tsukanov
@kekekeks
May 14 2016 11:43
PCL can't reference platform-specific assemblies
danwalmsley
@danwalmsley
May 14 2016 11:44
Ah
But designer knows
Nikita Tsukanov
@kekekeks
May 14 2016 11:44
Designer doesn't know
danwalmsley
@danwalmsley
May 14 2016 11:44
It always needs platform.win32
Nikita Tsukanov
@kekekeks
May 14 2016 11:44
Nope
danwalmsley
@danwalmsley
May 14 2016 11:44
Its never going to run on anything else?
Nikita Tsukanov
@kekekeks
May 14 2016 11:45
Designer process doesn't need anything but winforms and wpf
And relies on avalonia to set up things
And it won't have correct version anyway
danwalmsley
@danwalmsley
May 14 2016 11:46
Once you are on a release cycle the designer can be released along sode releases, and select based on which version of avalonia you target?
Nikita Tsukanov
@kekekeks
May 14 2016 11:58
@danwalmsley no, that't not a correct solution
One might use a custom build
One might use nightly feed
Designer should still work
It basically can't make speculations about platform binary locations at all
The only thing it looks for is Avalonia.DesignerSupport.DesignerAssist class with Init method
Steven Kirk
@grokys
May 14 2016 12:37
yep, i saw that standup when they announced project.json was going. quite a surprise. i'm glad we've not tried to port avalonia yet!
Darnell Williams
@Seeker1437
May 14 2016 13:47
@kekekeks maybe I PCL PLATFORM wrapper can be used
IPclPlatformWrapper can be used for that right?
Nikita Tsukanov
@kekekeks
May 14 2016 13:51
The problem is that IPclPlatformWrapper is implemented in Avalonia.Win32
Which isn't referenced by PCL
And needs to be located
Darnell Williams
@Seeker1437
May 14 2016 13:55
Ah a wrap
Okay
danwalmsley
@danwalmsley
May 14 2016 14:58
Project.json was cancelled?
Darnell Williams
@Seeker1437
May 14 2016 14:59
Yeah :(
They said they wold bring some features back over
Not pbv it isn't project.json
Matthijs ter Woord
@mterwoord
May 14 2016 15:01
eh?
dont really understand what the fuss is about though...
(i mean, why people desperately want the project.json)
Darnell Williams
@Seeker1437
May 14 2016 15:20
Because you don't have to explicitly add files and there were some other pluses
Nikita Tsukanov
@kekekeks
May 14 2016 16:56
It was good for cross-compilation
Jeremy Koritzinsky
@jkoritzinsky
May 14 2016 18:06
@grokys @kekekeks I think the reason that I extracted the Designer API was because it was causing weird dependency issues between the former Perspex.Application dll and the other dlls. Mainly, because of the DesignerApp class, there was a dependency on the XAML libraries as well as the Control libraries, so we couldn't move all of Perspex.Application into Perspex.Controls, but Application itself didn't have any of those dependencies. Basically, Perspex.Application became Perspex.DesignerSupport and the Application class was moved to Perspex.Controls.
Nikita Tsukanov
@kekekeks
May 14 2016 18:07
Application isn't really usable without xaml
Since our default theme is xaml-based
Jeremy Koritzinsky
@jkoritzinsky
May 14 2016 18:10
But Application itself as a class has no dependencies on XAML, just like how our controls have no dependency on XAML.
Steven Kirk
@grokys
May 14 2016 18:11
ok, yeah that sounds like good reasoning
Jeremy Koritzinsky
@jkoritzinsky
May 14 2016 18:11
@grokys wanted to move Application to Perspex.Controls and this was the only way to do it.
Nikita Tsukanov
@kekekeks
May 14 2016 18:12
So at current point the only thing that needs everything is designer api
And that actually makes sense, because if it's unable to find user's App class it needs to provide it's own
And it also needs to use xaml loader anyway
Steven Kirk
@grokys
May 14 2016 18:16
:+1: