@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?
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
It might be a huge structure
Doesn't look immutable to me
It might be a huge structure
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
because rendering is now threaded - if the main thread is changing something while the render thread is rendering you get a race
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
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
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
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
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
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
BTW, what is the plan on alpha5 release? I wanted to make iOS platforms use view-embedding too
and i keep getting sick
would be good to have them working again
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
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
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
Just remember to check compatibility matrix
where is this?
why cant we use 1.6?
oh its not released yet?
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?
There is support for converting PCL to .NETStandard
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
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
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
Let me check if you can build netstandard with 1.0.0-preview2-00313
You see, .NET Core tooling is currently a mess
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
?
And regarding package versions
You can't use ones from current nightly feed
You need to download packages from build 2600
oh ok
so you managed to get a new version of sprache or something?
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
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
looks like they're available in 1.0 to me: https://www.nuget.org/packages/System.ComponentModel.TypeConverter/
So we can keep targeting 1.1
value="C:\Users\keks\Projects\GitHub\Perspex\artifacts\nuget
this folder just contains all .nugetpkg files?
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?
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" },
But you probably need that
PackageTargetFallback for netstandard dlls
Or just use multitargeting support
So your project will target net45 and netcoreapp1.1
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
runtime targets, I mean
1380 new APIs
Yes I meant that if it works on 1.0 it work on 1.1 :)
It didn't find libSkiaSharp.dll for some reason
might be useful for that separate-thread renderer
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
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
and I'm trying to port to .net core
not sure if that class comes from avalonia
or msft?
We have full dotnet and mobile targets to support
well, yeah, Xamarin isn’t there yet
you are right
which is ReSharper
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
true
what is your laptop @kekekeks ?
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
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
but I would stay away from it like I said to @danwalmsley on AS
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
I see a bigger problem there
That is why they released only for uwp
@galvesribeiro @kekekeks so no reflection at all in .net core?
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?
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?
in tooling
dotnet/sdk#547
@danwalmsley
The bug is in .NET Core SDK
Unless there was some new SDK release recently
Try to use 1.0.0-rc3-004530
will try that
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
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.
<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
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
o.O
Is it .net core supported or just
net45+ ?
net core doesn't support it
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?
They have a host process
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'.
what does that do?
What's wrong with debugging?
It worked fine with both VS2015 and VS2017RC
You need to run that tool against that coreclr host exe
I can debug a new project if I create it
ok its something to do with having platform set to x86
@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
I’m able to run anything here without never touch on PE patches
in fact I never heard about it before :D
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
so console application
the
exe will open a console
I just asked how can we suppress this console
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
that is nice
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
but @kekekeks that only work on windows, right?
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
And for these systems there is no such concept as "GUI" and "CUI" applications
this guy from .net team is using a “console app” to build his game engine
you need a terminal emulator app, kernel-provided terminal emulator (tty0-9) or some kind of COM port
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 also do you know what happened to InheritedExport in the new System.Composition?
netstandard I mean
nice
.Net Core is indeed faster
Build 2600 on CI server
We haven't announced it properly yet, since it needs to be merged first
but it is using the old tooling as I see
But there are .NETStandard versions of GTK/Win32 backends and Skia renderer
And want to keep Travis CI build running
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
So I've limited project.json usage to 4 projects
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
Once VS2017 is released, we'll probably switch to new msbuild tooling right away