These are chat archives for AvaloniaUI/Avalonia

12th
Oct 2017
fanoI
@fanoI
Oct 12 2017 07:39
Avolonia UI needs to run in the special stathread or not?
Steven Kirk
@grokys
Oct 12 2017 07:44
@fanoI STA thread is a COM concept and avalonia doesn't use COM. but you need to interact with it on the UI thread, yes if that's what you mean
fanoI
@fanoI
Oct 12 2017 08:02
So as in Winform / WPF I cannot call directly methods to change the UI (I know it is bad code) but I'd liked to use it with Akka .Net and it has problems with threads that need to run on the STA thread... I don't see the attribute on the main application is set behind the scenes?
Nikita Tsukanov
@kekekeks
Oct 12 2017 08:50

COM concept and avalonia doesn't use COM

I think our folder selection dialog uses COM, but it seem to work without thread apartment

@fanoI you still can't change UI from non-UI thread in Avalonia
Use Dispatcher.UIThread.InvokeAsync
Steven Kirk
@grokys
Oct 12 2017 15:32
@kekekeks can we merge Avalonia.Win32 and Avalonia.Win32.NetStandard? afaics the netstandard version just differs in the way icons are implemented, right? can we just use the netstandard way on both platforms?
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 15:40
We can also copy the icon implementation from System.Drawing in corefx so we can have the implementation on netstandard
Steven Kirk
@grokys
Oct 12 2017 15:46
yeah, or depend on System.Drawing under netstandard?
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 15:58
System.Drawing isn't released under netstandard AFAIK. I'll check
Yeah it's only on netcoreapp2.0 as a preview package
We could multitarget for net461, netcoreapp2.0, and netstandard and have the netstandard implementation just be our dummy implementation
danwalmsley
@danwalmsley
Oct 12 2017 16:51
@kekekeks i saw you mentioned drag and drop support the other day
I'm probably going to need that soon, so I will have a look to see what Uwp, wpf does
I was thinking however of when you have datacontext that implements IDragDrop or something
Then perhaps that could enable it, at datacontext level, so you could handle drag drop in viewmodels
Then rather than dropping the control itself, the datacontext from the source control gets dropped onto datacontext of destination control
This would be in addition to normal drag drop at control level
That probably could be implemented as a behaviour actually
Matthijs ter Woord
@mterwoord
Oct 12 2017 16:58
i faked it manually.. :)
danwalmsley
@danwalmsley
Oct 12 2017 17:00
Do you have a nice example?
Matthijs ter Woord
@mterwoord
Oct 12 2017 17:00
i can show some stuff tomorrow if you want..
comes down to some trickery in Mouse events
OnPoitnerPressed, OnPointerMoved and OnPointerReleased
my use case is having a dashboard where the user can move widgets around
(and later on add/remove them)
danwalmsley
@danwalmsley
Oct 12 2017 17:08
If you could that will be great 😀
Oh @grokys one thing we should definitely fix for the beta release i don't know if there is already an issue
Matthijs ter Woord
@mterwoord
Oct 12 2017 17:10
please nudge me again tomorrwo or saturday. i most likely will forget things.. :)
danwalmsley
@danwalmsley
Oct 12 2017 17:10
But now we have screen api
Matthijs ter Woord
@mterwoord
Oct 12 2017 17:10
i can show you around to what i did and what i'll need
danwalmsley
@danwalmsley
Oct 12 2017 17:10
Context menus can obey screen edges
@mterwoord i will, thanks ☺
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 17:32
@danwalmsley I think we might have to push that off past beta 1. We can't keep adding features or we'll never release.
danwalmsley
@danwalmsley
Oct 12 2017 17:34
Context menu stuff?
Should be a very small feature
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 17:36
Yeah. Unless it's super quick we really need to do a feature freeze on beta 1 and just finish all of the issues we currently have assigned to the Pre-Beta, Beta 1, and 0.6.0 milestones and projects.
danwalmsley
@danwalmsley
Oct 12 2017 17:40
Sure, il look into what's involved, for me this particular problem with context menu, i see as a bug, it makes Avalon Studio very hard to use on small screens amd I'm hoping to get Avalon Studio to stablise too and use the Beta version of Avalonia from Beta 1 onwards
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 17:41
Sounds good.
Btw for everyone here, we currently have about 64 issues that we want to close/fix or punt for beta 1. Some of these might already be complete, so take a look through and close ones that have already been fixed.
Darnell Williams
@Seeker1437
Oct 12 2017 17:49
I no longer have access so I'll post in here stuff
And comment
danwalmsley
@danwalmsley
Oct 12 2017 17:52
@jkoritzinsky is that this stuff here https://github.com/AvaloniaUI/Avalonia/milestone/4?
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 17:53
It's the Pre-Beta and Beta1 milestones, and the 0.6.0 Project.
danwalmsley
@danwalmsley
Oct 12 2017 18:08
@jkoritzinsky can I add this to beta1 milestone...
AvaloniaUI/Avalonia#1182
also this one, AvaloniaUI/Avalonia#1143 which is probably fixed now, but at least needs checking ready for beta
this is also a bit of a show stopper
AvaloniaUI/Avalonia#1142
danwalmsley
@danwalmsley
Oct 12 2017 18:14
AvaloniaUI/Avalonia#809 is another easy one that really should be there
i wont add them unless you agree though
I can probably fix a few of these anyway
Steven Kirk
@grokys
Oct 12 2017 19:55
@danwalmsley @mterwoord regarding drag and drop, i wrote a frameworks for that a long time ago that punker76 took over maintenance of: https://github.com/punker76/gong-wpf-dragdrop
regarding #1182, did you manage to work out what it was?
Nikita Tsukanov
@kekekeks
Oct 12 2017 19:57

can we merge Avalonia.Win32 and Avalonia.Win32.NetStandard? afaics the netstandard version just differs in the way icons are implemented, right? can we just use the netstandard way on both platforms?

I think it has some winforms-related code

for previewer and interop

We could multitarget for net461, netcoreapp2.0, and netstandard and have the netstandard implementation just be our dummy implementation

@jkoritzinsky I don't like dummy implementations. That's why we had issues with ReactiveUI in the first place. It's better to copy-paste some code from Mono's System.Drawing implementation

Steven Kirk
@grokys
Oct 12 2017 20:00
hmm travis osx seems to be failing
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:02
It can't install openssl from brew
Which isn't even needed for .NET Core 2.0
We can probably fix it by manually installing the SDK
But I'd rather disable OSX build
It's always slow and we don't really need it
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 20:09
For the system.drawing related classes, let’s copy from Microsoft’s implementation in corefx.
Or the Avalonia.Win32 package could just target netcoreapp2.0 and net461 and not target netstandard2.0. Both of those options would work
Eric Dunaway
@EricDunaway
Oct 12 2017 20:12
any reason not to use the system.drawing in netstandard 2.0?
https://docs.microsoft.com/en-us/dotnet/api/system.drawing?view=netstandard-2.0
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 20:12
And for dummy implementations I was thinking an icon implementation like we have for iOS or Android
The classes we need aren’t in the netstandard2.0 subset of System.Drawing
They’re in going to be in .Net Core 2.1 and are available in .net core 2.0 via a preview package
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:15
@GrimR3 I don't think that netstandard version has HICON loading support

let’s copy from Microsoft’s implementation in corefx.

Have you checked if it works with icons? One from Mono certainly does

Steven Kirk
@grokys
Oct 12 2017 20:30
Yeah let's disable the osx build then, at least for now
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:31

They’re in going to be in .Net Core 2.1 and are available in .net core 2.0 via a preview package

I'm not sure if we want to bump the minimum version of .NET Core again

Nikita Tsukanov
@kekekeks
Oct 12 2017 20:32
We've already lost support for OSX < 10.12 by upgrading to .NET Core 2.0
@GrimR3 it's not on nuget.org, right?
So we can't use it
nugget version
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:41
Ah, OK
Let's use it then
Wait
It's 600KB
in one dll
Let's not use it then )
Our entire win32 backend is 68KB
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:49
I think there also was some issue with multitargeting and Linux/OSX build
And IDE support
Until that's fixed, it's better to either use netstandard or separate projects
I'll figure something about icon loading
Eric Dunaway
@EricDunaway
Oct 12 2017 20:50
Source: https://github.com/dotnet/corefx/tree/master/src/System.Drawing.Common/src/System/Drawing
you could just copy the icon class like @jkoritzinsky suggested
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:51
Yeah, it's better to do it that way
We already have some code copy-pasted from Mono
The problem was with loading actual .ico files from memory
Win32 API doesn't have a built-in function to do that
And Mono implementaion was quite complex to just copy-paste while doing the task at hand
Jeremy Koritzinsky
@jkoritzinsky
Oct 12 2017 20:54
The icon class in system.drawing.common has that support.
Nikita Tsukanov
@kekekeks
Oct 12 2017 20:55
I think it's the same code, actually
Yeah, seems to be imported from Mono
Hmmm....
Wait
The code in their icon.cs only loads one of the icons
To be honest, at this point I'd rather save the icon to temporary file and load it from there using winapi
Nikita Tsukanov
@kekekeks
Oct 12 2017 21:07
Mkay, I see
There are two versions of Icon.cs there
one from mono (in Unix directory), another seems to originate from the original System.Drawing
danwalmsley
@danwalmsley
Oct 12 2017 22:29
@grokys will test your PRs #1205 , #1206 & #1210 first thing in the morning with AS
re #1182 unfortunately I didn't get very far :(
danwalmsley
@danwalmsley
Oct 12 2017 22:36
just tested #1143 and its still an issue
its quite easy for someone just hacking around that creates a new avalonia project to come across that
has a very easy repro too
image.png
Nikita Tsukanov
@kekekeks
Oct 12 2017 23:51
@grokys renaming up-for-grabs to help-wanted makes it invisible to http://up-for-grabs.net/