@kekekeks I pushed my wip AppKit and quartz rendering to my fork's OSX branch if you want to take a look.
Any way to add color formatting to a "TextBox" object or equivalent?
@zezba9000 I had to write my own text editor control from scratch to support that
you can only set all the text to 1 colour
or 1 text style
(or it was last time I tried)
FormattedText itself has support for some formatting (colors, I think), while textbox doesn't
@kekekeks can formatted text be used directly as a control?
It should be easy to wrap it, I think
You can access it in TextBlock
But I'm not sure that it will work with new "everything is immutable" concept by @grokys
WPF uses locks for such things, I think
FormattedText isn't immutable, it's FormattedTextImpl that is
And I don't think that's a good idea
It might be a huge structure
Doesn't look immutable to me
ah yeah that needs changing
It might be a huge structure
It will be too overhead
Imagine something like 100KB of text with each symbol of different color
And for immutability support you need to copy all that information on each call to SetForegroundBrush
yeah, i'm open to suggestions
What exactly do you need that immutability for?
because rendering is now threaded - if the main thread is changing something while the render thread is rendering you get a race
WPF handles that with locks
And they have a very specific type for bitmaps that can be changed by user code
Which need to be explicitly locked to be altered
afaik WPF's renderer doesn't use managed objects - it's all in non-managed code
Yep, but it does use locking
again, afaics the renderer doesn't share the WPF objects
it shares underlying implementations
to WPF control
I noticed that when I needed to render from unmanaged bitmap
My code had very poor performance in some cases
for bitmaps maybe, i'm trying to find where i saw it, but as far as i remember it serializes formatted text to send it to milcore
Because it had to wait for locks
Since bitmap was locked by the render thread
I had to workaround that with kind of spin lock
i. e. if UI thread can't lock bitmap right now, enqueue delegate to the event loop and try again
Well, our skia implementation of FormattedText is completely managed one
so we can get away with that
But for Direct2D1 backend you need to clone underlying implementation
Wait
Do you need it to actually be immutable?
Or be clonable
Because in case of cloning there is no much overhead
yeah cloneable would work
Or even better
Copy-on-write
Basically, all clones share the same data structures
Until one of them needs to be altered
In this case it will switch to its own copy of data structures
well COW is a form of immutability
but yes that would work
So if there are no currently attached clones, FormattedText will just access it's data structures directly
The way I got around it in the Avalon studio editor, was to only render the text visible on the screen
Hm
Wait, we don't need "clones"
we need snapshots
So if FormattedText is asked for a snapshot it could reuse a previous one
The way I got around it in the Avalon studio editor, was to only render the text visible on the screen
That optimization should go to FormattedText
Since we have line information there
Well, line wrapping will still cost some performance, but still
i think the control itself should probably do the clipping
BTW, what is the plan on alpha5 release? I wanted to make iOS platforms use view-embedding too
i wanted to do one soon, but people keep sending PRs ;)
and i keep getting sick
if you wanted to sort out iOS platforms, we can wait for that
would be good to have them working again
I also need to make changes for popups
On Android we need to pass parent window
And for that it would be nice to have that .NET Core merged, since it contains a whole new GTK3 backend
Well, I could workaround that parent view requirement by using something like this: http://stackoverflow.com/a/38650587/2231814
so the .NET core support PR isn't just .NET core, it's also gtk3?
i will review asap, got a lot of work to catch up with
PR isn't just .NET core, it's also gtk3?
There are currently some stubs (win32 icons, window state on GTK3), but in general it works well
@kekekeks for porting Avalon studio
which .net class library type do I need to use
portable and .net standard 1.5?
there are so many different permiatations of portable libs I have no idea what I'm looking at now
PCL7 should work just fine
And you probably won't be able to build netstandard1.6 anyway
So either PCL or .net standard 1.5
Oh, wait
You probably want to have P/Invoke
So .net standard, that's it
ok thanks
Just remember to check compatibility matrix
I'll go with .net standard 1.5
Just remember to check compatibility matrix
where is this?
.NET 4.5 is only compatible with .NETStandard 1.1
so 1.6 and below is compatible with .net core 1?
why cant we use 1.6?
oh its not released yet?
Not compatible with desktop .NET
For some weird reason
AppVeyor is even unable to build it
is there a nice way to upgrade .net 4.6 class lib to the new format?
Not one I know about
There is support for converting PCL to .NETStandard
so we just have to create a new project
and manually add each file again?
So you could basically create a PCL, convert to .NETStandard and then copy-paste your project items from another csproj
And change project GUID
NETStandard project files look somewhat like this:
https://github.com/kekekeks/Perspex/blob/d0e691554231517246e342fe740d6c42b6555a8b/src/Windows/Avalonia.Win32.NetStandard/Avalonia.Win32.NetStandard.csproj
https://github.com/kekekeks/Perspex/blob/d0e691554231517246e342fe740d6c42b6555a8b/src/Windows/Avalonia.Win32.NetStandard/Avalonia.Win32.NetStandard.csproj
BTW, you will lose the ability to build with Mono
as long as it will run on .net core
I don't care about mono after that
or should I?
Not sure if you'll be able to build it using .NET Core SDK on linux
It's... complicated
but the binaries will run?
Yep
that's better
I want to build once on appveyor
and use the same binaries
It might be better to have P/Invoke-related stuff in a nuget package
except native libs
You probably still want to debug
Let me check if you can build netstandard with 1.0.0-preview2-00313
You see, .NET Core tooling is currently a mess
preview 4 would be better?
it was released only last friday
You can build .NETStandard using old
msbuild and csproj (with project.json for nuget dependencies) with VS2015, but not XBuild
@kekekeks can I use current avalonia nugget in .net standard?
You can build .NETStandard using
project.json-based tooling, but won't be able to reference those binaries from csproj
You can also install VS2017 and build everything using new msbuild
But for some reason it does not run Avalonia properly
Package Sprache 2.0.0.51 is not compatible with netstandard1.5
Can't find libSkiaSharp.dll from nuget
I'm using vs2017
well, good luck with that
how did you get sprache to be compatible
?
I haven't managed to run it under debugger
And regarding package versions
You can't use ones from current nightly feed
You need to download packages from build 2600
ah I need to wait for your pr to be merged?
oh ok
so you managed to get a new version of sprache or something?
2.1
There is also some wicked dependency magic (
netcoreapp1.0profile references more recent package versions which are not compatible with PCL)
So I'm not sure that you even can use avalonia from "NETStandard" right now
From .NET Core, you can
It's serilog and splat actually
That need specific versions
Once new tooling is released, we'll probably switch to .NETStandard2.0 completely and ditch xbuild support
Well, we might want to keep core assemblies compatible with .NETStandard1.1 to have .NET 4.5 support
But @grokys really wants those type converters from .NETStandard2.0, so...
yeah, typeconverters would be a massive help. basically, at the moment control authors are stuck with our predefined typeconverters
And that's .NET 4.6.1 as minimum framework for us
But who cares if you can bundle .NET Core runtime with your app
well tbh i think typeconverters are available in <.netstandard 2.0
i can't find the table that lists what's available where though any more
For .NET 4.5 we need .NETStandard 1.1
looks like they're available in 1.0 to me: https://www.nuget.org/packages/System.ComponentModel.TypeConverter/
Nice
So we can keep targeting 1.1
@kekekeks
value="C:\Users\keks\Projects\GitHub\Perspex\artifacts\nuget
this folder just contains all .nugetpkg files?
Yep
Well, we could upload them to a separate feed, but it will be temporary anyway
Package Avalonia 0.4.1-build2600-alpha is not compatible with netstandard1.5 (.NETStandard,Version=v1.5). Package Avalonia 0.4.1-build2600-alpha supports:
- net45 (.NETFramework,Version=v4.5)
- netcoreapp1.0 (.NETCoreApp,Version=v1.0)
- portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
Package Serilog 1.5.14 is not compatible with netstandard1.5 (.NETStandard,Version=v1.5). Package Serilog 1.5.14 supports:
- net40 (.NETFramework,Version=v4.0)
- net45 (.NETFramework,Version=v4.5)
- portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
Package Splat 1.6.2 is not compatible with netstandard1.5 (.NETStandard,Version=v1.5). Package Splat 1.6.2 supports:
- monoandroid (MonoAndroid,Version=v0.0)
- monomac (MonoMac,Version=v0.0)
- monotouch (MonoTouch,Version=v0.0)
- net45 (.NETFramework,Version=v4.5)
- netcore45 (.NETCore,Version=v4.5)
- portable-net45+win8+wp8+wpa81 (.NETPortable,Version=v0.0,Profile=Profile259)
- portable-win81+wpa81 (.NETPortable,Version=v0.0,Profile=Profile32)
- wp8 (WindowsPhone,Version=v8.0)
- xamarinios10 (Xamarin.iOS,Version=v1.0)
- xamarinmac10 (Xamarin.Mac,Version=v1.0)
One or more packages are incompatible with .NETStandard,Version=v1.5.
Package restore failed. Rolling back package changes for 'AvalonStudio.Extensibility'.
how did you get it to work .net standard?
dotnet/sdk#391
I didn't
My project is targeting .NET Core
But you can use that
PackageTargetFallback
And for splat and serilog just reference more recent versions
new NuSpecDependency() { Id = "Splat", TargetFramework = "netcoreapp1.0", Version = "2.0.0" }, new NuSpecDependency() { Id = "Serilog", TargetFramework = "netcoreapp1.0", Version = "2.3.0" },
netcoreapp 1 or 1.1?
I was targeting netcoreapp1.0
1.1 should be ok too I guess?
But you probably need that
PackageTargetFallback for netstandard dlls
Or just use multitargeting support
So your project will target net45 and netcoreapp1.1
it worked!
That's not updated for VS2017
But there you can have something like
<TargetFrameworks>net45;netcoreapp1.1</TargetFrameworks>
And
<ItemGroup Condition="'$(TargetFramework)' == 'net45'">
<PackageReference Include="DesktopOnlyDependency">
<Version>1.0.0</Version>
</PackageReference>
</ItemGroup>
For framework-specific deps
But it's better to use .NETStandard1.1 if possible
1.1 has same surface as 1.0
1.1 has support for more targets
runtime targets, I mean
1380 new APIs
Yes I meant that if it works on 1.0 it work on 1.1 :)
I wasn't able to run with VS2017
It didn't find libSkiaSharp.dll for some reason
might be useful for that separate-thread renderer
yeah i saw that
it will be useful generally i think!
Oh my, just reading the trouble you have with .net standard / .net core configurations and targeting makes me happy my work project is still targeting Framework 4.6. But I'm really looking forward to the moment I can just start a .net core project with avalonia without jumping through too many hoops. You are heroes for the work you do.
Once VS2017 is released, we'll just switch to .NETStandard1.1 and forget about these difficulties
btw
with the recent (yesterday) update VS2017 got SOOOO more stable, specially with .net core tooling
it is usable again finally
@grokys @kekekeks is there a type converter class now in nugget package or does avalonia give me this?
but if I may suggest, you guys should use VSCode for Avalonia once you migrate the projects to the new target
@danwalmsley not sure what you mean
some of my code inherits typeconverter
and I'm trying to port to .net core
not sure if that class comes from avalonia
or msft?
VSCode
Thank you, but no
We have full dotnet and mobile targets to support
And?
well, yeah, Xamarin isn’t there yet
you are right
VS Code also lack one very significant thing
which is ReSharper
ic
I don’t use it
it eats a lot of CPU/Memory
and VS is already too bloated to make it even more
not to mention that all the nice refactory stuff are already there
so I dont miss it
it eats a lot of CPU/Memory
It's not an issue if your laptop has i7-4800MQ and 32GB RAM
And 1TB+256GB SSD... and 1.5TB HDD...
You know, things that Apple laptops usually lack
hahaha
true
what is your laptop @kekekeks ?
Dell M4800
Ahh, mobile workstation
nice
I’m considering the new Precision 52xx
they are really thin
and has Xeon proc with 32gb RAM and 1tb m.2 SSD
my surface pro 3 died with battery and I shipped to service, so unfortunately I’m working in a MacMini
i7 16gb but with a crap HDD
Consider their customization options
You can get 64GB RAM that way
And regarding macs... I could live with poor hardware, but their keyboards are just unusable
My Dell comes with proper PC 101-key keyboard and trackpoint and two sets of hardware mouse buttons (3 buttons each)
I was using thinkpads before, but they've moved PrintScreen to inappropriate position and that was a show-stopper for me
@danwalmsley it seems that .NET Core 1.1 has MEF built-in or something
Yeah it has a lightweight version of MEF
but I would stay away from it like I said to @danwalmsley on AS
I wonder what state corert is currently in
It would be nice to avalonia-app to native code
Could even be a feature that will bring more user base to the project
The problem is reflection which I believe you rely on while binding
And btw corert have a release this week for uwp
dotnet/corert#669
I see a bigger problem there
Yup
That is why they released only for uwp
@galvesribeiro @kekekeks so no reflection at all in .net core?
corert
Curious... how do you guys deal with xaml here? Is it pre-compiled at build time into a c# type or it is parsed in runtime?
xaml is parsed at runtime and uses reflection
there's an attempt underway to convert XAML into C# here: cwensley/Portable.Xaml#41
@kekekeks when you ported to .net core did you have problems with references?
i.e. I have Project C -> Project B -> Project A
referencing like that
on .net core I have to get C to reference B and A directly to get it to compile
I didn't have to do that previously
do you know why that might be?
It's a known bug
in tooling
dotnet/sdk#547
@danwalmsley
so its just a problem in visual studio
Yep
when I build from command line it will be ok?
Probably no
The bug is in .NET Core SDK
Unless there was some new SDK release recently
Try to use 1.0.0-rc3-004530
there is a visual studio update since yester day
will try that
Wow
RC3 fixed the issue with running on Ubuntu 15.10
I had to edit /etc/os-release to make it think that it's running on 14.04
I'm not updating it on my windows installation however
Since I have some production code that's built using the current SDK
and I've noticed some breaking changes
have you seen this error?
Yep
That's one of the breaking changes
Remove <Compile Include="*.cs"> from your project
Fixed Nuget Restore operation issue in scenarios where a project uses both PackageReference elements to manage NuGet packages, and has a reference to another project in the solution.
this is bleeding edge!
I really like how new csproj files look like
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
<AssemblyName>ControlCatalog</AssemblyName>
<OutputType>Exe</OutputType>
<RuntimeIdentifiers>win7-x64;ubuntu.14.04-x64</RuntimeIdentifiers>
<GenerateAssemblyConfigurationAttribute>false</GenerateAssemblyConfigurationAttribute>
<GenerateAssemblyCompanyAttribute>false</GenerateAssemblyCompanyAttribute>
<GenerateAssemblyProductAttribute>false</GenerateAssemblyProductAttribute>
</PropertyGroup>
<ItemGroup>
<EmbeddedResource Include="**\*.resx" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
<EmbeddedResource Include="**\*.xaml;Assets\*;compiler\resources\**\*" Exclude="bin\**;obj\**;**\*.xproj;packages\**" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Avalonia">
<Version>1.0.0-test6</Version>
</PackageReference>
<PackageReference Include="Avalonia.Skia.Desktop">
<Version>1.0.0-test6</Version>
</PackageReference>
<PackageReference Include="Avalonia.Win32">
<Version>1.0.0-test6</Version>
</PackageReference>
<PackageReference Include="Avalonia.Gtk3">
<Version>1.0.0-test6</Version>
</PackageReference>
</ItemGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<DefineConstants>$(DefineConstants);RELEASE</DefineConstants>
</PropertyGroup>
</Project>
And that's it
Well,
<Compile Include="**\*.cs"> was supported by msbuild ages ago
But VS wasn't very happy with that
@kekekeks you can still use it if you want
it is just not required anymore
there is a tag that makes the new tooling don't add the files automatically
<EnableDefaultCompileItems>false</EnableDefaultCompileItems>
that does it
if you aren't ready to migrate to new reduced project format, just add it and you are safe
@kekekeks does application type need to be console application or Windows?
@danwalmsley for .net core it is a console application always today
even if you are spinning a server up
or web app
in the end it is a console app
@danwalmsley set
OutputType type to WinExe
were you able to debug?
WinExe? That is new
o.O
Is it .net core supported or just
net45+ ?
Hm
net core doesn't support it
what debugging?
so it builds and produces AvalonStudio.dll
dot net run wont run it
unless I make it a console app
how do I run it?
why doesn't it output an exe?
That's how .NET Core runs binaries
They have a host process
ok
which is a native (not .NET) executable
fair enough
but dotnet run wont execute it
if its winexe
Unable to run your project.
Please ensure you have a runnable project type and ensure 'dotnet run' supports this project.
The current OutputType is 'winexe'.
I had PE file patcher somewhere
how did you run control catalog?
what does that do?
That can change SUBSYSTEM in PE headers
so absolutely no way to debug?
What's wrong with debugging?
It worked fine with both VS2015 and VS2017RC
You need to run that tool against that coreclr host exe
Are you able to set a breakpoint in your
Main method?
it crashes before it manages to load the symbols
Mkay, so I'm definetely not updating my installation
hahaha
I can debug a new project if I create it
ok its something to do with having platform set to x86
It doesn't work well with x86, I think
I though skiasharp required it
wait
or has that gone away?
hy are you changing the dot net?
@kekekeks you have to explain what this changing the subsystem thing is?
@danwalmsley it is not
dotnet run something it is dotnet yourdll.dll
run is only used to run from the project directory
ok @galvesribeiro thanks
I’m able to run anything here without never touch on PE patches
in fact I never heard about it before :D
I'm not sure why we would need to
still
just spoke with someone from dotnet cli team here, they told thta winexe should not work anymore
it was an old target for
net TFM
and only on windows
ok
so console application
the problem is
the
exe will open a console
I just asked how can we suppress this console
woohoo debugging is working
you have to explain what this changing the subsystem thing is?
@danwalmsley toggling between console and non-console application essentially
IMAGE_SUBSYSTEM_WINDOWS_CUI - console executable
IMAGE_SUBSYSTEM_WINDOWS_GUI - "normal" executable
So after you publish your app
ahh
that is nice
It will create
AvalonStudio.dll and AvalonStudio.exe
Second one is .NET Core Host application
Which is console app
So you need to patch subsystem there
hey quick note for everyone using the new project system. you can also use it for older projects like net45 targeting libraries
To make it win gui
@jkoritzinsky yes you can
but @kekekeks that only work on windows, right?
Im using that for AvaloniaAV
Yep
ok
So it is a nogo for @danwalmsley
Because other platforms are using their own versions of .NET Core host
there must be an (undocumented yet) way to suppress the console
which are not PE files
yup
but ELF and Mach-O executables
And for these systems there is no such concept as "GUI" and "CUI" applications
yes
Every executable has stdin, stdout and stderr
this guy from .net team is using a “console app” to build his game engine
And if you want to interact with those channels
you need a terminal emulator app, kernel-provided terminal emulator (tty0-9) or some kind of COM port
and there is no console being opened
There is
kernel32!FreeConsole function
But it's better to just patch subsystem of the launcher
And console is useful in debug mode anyway, so there is no point of disabling it unless you are publishing binaries
I had C# code to do that somewhere
But it was like 5 years since I've last used it
So I can't find it
@mellinoe Eric are you around?
@mellinoe also do you know what happened to InheritedExport in the new System.Composition?
Avalon studio running on .net core! partially!
did Avalonia got updated to .net core? o.O
netstandard I mean
there is a test build available
oh, didn’t knew
nice
@galvesribeiro loads quicker too!
yeah
.Net Core is indeed faster
@galvesribeiro https://www.youtube.com/watch?v=UHEW-ZInr6A
Build 2600 on CI server
cool!
We haven't announced it properly yet, since it needs to be merged first
sure
but it is using the old tooling as I see
It works as well with the new one
ok good
Core libraries are still PCL Profile7
humm
But there are .NETStandard versions of GTK/Win32 backends and Skia renderer
I though you would make all them netstandard
We are stuck with VS2015 for now
And want to keep Travis CI build running
right
So moving everything to netstandard is troublesome
Travis dont work with .net core?
You see, we need to reference these projects from Xamarin platforms
So we have to use MSBuild tooling for avalonia libraries
We also don't want to use project.json and then have to do another migration
you can use netstandard nugets on Xamarin, can’t you?
yep
u are right
VS2015 tooling is a mess of msbuild and project.json
So I've limited project.json usage to 4 projects
yes
just wait then
migrate and announce the upgrade later
when you are confortable with VS2017
Basically now we have separate projects for NETStandard versions of backends
That have the same assembly name
And get included to nuget packages under
netcoreapp1.0 runtime
It's a bit of a mess, but it works
Yeah, but man, no rush with that
Once VS2017 is released, we'll probably switch to new msbuild tooling right away
Wait util vs2017
I don't think that will be much longer
yup