Avalonia – A multi-platform .NET UI framework(github.com)
github.com
Avalonia – A multi-platform .NET UI framework
https://github.com/AvaloniaUI/Avalonia
9 comments
I was looking for something like this after .NET Core 1.0 announce. I am just waiting for it to be compatible with .NET Core. Any plans for making it compatible?
Great job!
Great job!
Yep! The main thing that's holding me back personally is that we'd have to convert our .csprojs to project.json... And then convert them back in a few months/a year when core moves back to .csproj. So seems like wasted effort to me right now...
Nice work. Looking forward to .NET Core support.
I assume this is the relevant issue? https://github.com/AvaloniaUI/Avalonia/issues/314
I assume this is the relevant issue? https://github.com/AvaloniaUI/Avalonia/issues/314
Why are they moving back to .csproj?
See the official statement here: https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-t...
There was nothing wrong with csproj, apart from the MSBuild verbosity baggage. JSON's a terrible format for anything like this due to lack of comments and visual noise. (The mandatory quotes all over the place makes it hard to read.)
But I can't imagine it is hard to convert between them. Most .csproj's are basically a list of references and a <Compile><Include>*.cs.
But I can't imagine it is hard to convert between them. Most .csproj's are basically a list of references and a <Compile><Include>*.cs.
For a non professional developer, it is almost entertaining to watch all the fads coming and going.
XML is fantastic, all data XML!
XML is horrendous. All data in JSON. I can't believed we were using this awful XML!
JSON is sooo lame. XML is the new JSON!
Same for languages, frameworks, programming patterns, etc...
Even more volatile than fashions.
XML is fantastic, all data XML!
XML is horrendous. All data in JSON. I can't believed we were using this awful XML!
JSON is sooo lame. XML is the new JSON!
Same for languages, frameworks, programming patterns, etc...
Even more volatile than fashions.
While some people get a bit cargo cult about things there is a rough consensus that XML is good for some things and terrible for others whilst JSON is the exact reverse ;-)
I personally rather like YAML for anything intended for humans to read and edit.
I personally rather like YAML for anything intended for humans to read and edit.
If XML didn't have those idiotic verbose closing tags, this probably wouldn't even be a discussion. Or if JSON had comments and didn't require quoting all keys.
What's funnier is seeing the HTTP/JSON folks re-invent SOAP. But maybe this time it'll actually be Simple.
What's funnier is seeing the HTTP/JSON folks re-invent SOAP. But maybe this time it'll actually be Simple.
Do you have any plans to implement accessibility? On Windows, you should probably implement a UI Automation provider. For GTK-based platforms, I guess you need to use ATK. You'll need an accessibility API of your own to abstract over the multiple back-ends; maybe copy what Gecko has in its nsIAccessible and related interfaces.
Yes this is definitely something we need to do. Unfortunately it's not something I'm very familiar with, but contributions welcome! ;)
Are there any plans to support styling so you can get a native look-and-feel on non "Modern" Windows operating systems?
There's already https://github.com/picoe/Eto if you want to use native controls - if that's what you need go for it! But there's a need for both approaches IMO and hopefully Avalonia can start to fill one of those!
EDIT: Ah you edited your question: yes controls are fully styleable - the reason we've got the "modern" look so far is simply because it's easy! More themes, and "native" looking themes are definitely welcome.
EDIT: Ah you edited your question: yes controls are fully styleable - the reason we've got the "modern" look so far is simply because it's easy! More themes, and "native" looking themes are definitely welcome.
It looks like Eto doesn't plan to support .NET Core. https://github.com/picoe/Eto/issues/457
But this might change if a framework like Avalonia adds Core support.
But this might change if a framework like Avalonia adds Core support.
Any chance you plan on supporting UI's for Unity3d?
Not really thought about unity in particular, but we do have game ui as a potential use-case.
Would this potentially work with Monogame, as that's built on the same framework?
Honestly - no idea. However our backends are pluggable so in theory you should be able to adapt it.
However, I imagine our performance at the moment exclude use in games. It's something that needs to be optimized.
However, I imagine our performance at the moment exclude use in games. It's something that needs to be optimized.
What graphics backend do you use there?
If you want it to be used in games then on Windows, for example, Direct2D is the only reasonable option.
It will allow to render UI on layers inside DirectX 3D scenes: http://sciter.com/sciter-and-directx/
If you want it to be used in games then on Windows, for example, Direct2D is the only reasonable option.
It will allow to render UI on layers inside DirectX 3D scenes: http://sciter.com/sciter-and-directx/
Yep, we have a Direct2D backend (in fact that's our main one - the others are lagging behind a little)
Anything around graphing yet? Or Is that still something that I would need to roll with SyncFusion, Telerik or something similar.
No not currently - were still working on the core at the moment, though I think we're just about ready for it now if anyone was interested in starting on it.
Maybe Avalonia support can be added to OxyPlot (https://github.com/oxyplot/oxyplot/tree/develop/Source). It's already portable with a bunch of rendering targets.
what is the support for custom controls like? (i.e. inheriting from a canvas and drawing themselves, while being added as a new widget type to the layout code.)
Custom controls are supported, although I'm not sure that inheriting from Canvas is the best way to do that. See e.g. https://github.com/Core2D/Core2D for an example of an application with lots of custom controls.
The support is great, you can see this example [1] of using custom rendering in Canvas being part of UI layout [2]. You can also see Avalonia in action here [3].
[1] https://github.com/wieslawsoltes/SpiroNet/blob/master/src/Sp...
[2] https://github.com/wieslawsoltes/SpiroNet/blob/master/src/Sp...
[3] https://youtu.be/wZK9MPR_UeE
[1] https://github.com/wieslawsoltes/SpiroNet/blob/master/src/Sp...
[2] https://github.com/wieslawsoltes/SpiroNet/blob/master/src/Sp...
[3] https://youtu.be/wZK9MPR_UeE
[deleted]
Interesting, .NET Core doesn't have a good UI story yet. It's just console / web for now. Something like WPF but cross-platform would be great and this looks promising.
My Sciter Engine [1] with C# wrappers [2] for .NET and Mono is on par with WPF[3]. It just uses HTML and CSS instead of that XAML thing.
[1] http://sciter.com [2] http://www.codeproject.com/Articles/1057199/Sciter-HTML-Csha... [3] http://sciter.com/sciter/sciter-vs-wpf/
[1] http://sciter.com [2] http://www.codeproject.com/Articles/1057199/Sciter-HTML-Csha... [3] http://sciter.com/sciter/sciter-vs-wpf/
I'm sorry, but in terms of convenience and flexibility of desktop UI development, HTML/CSS/JS is simply not the same thing as WPF. HTML is ultimately still a document markup language originating in a stateless environment, and it shows.
Standard HTML5 is quite limited in terms of UI, yes.
But in Sciter you can define even windows as HTML. Check this: http://sciter.com/images/sciter-clock.png, this is HTML and CSS[1]. Can you do that in browser or even in WPF?
I've also introduced <popup> element that allows to render DOM elements as popups outside HTML canvas (in separate windows) : http://terrainformatica.com/w3/sciter-tooltip.png
Yet all screenshots on http://sciter.com are HTML/CSS as they use Sciter for the UI. Essentially all AV vendors. Only Kaspersky AFAIK uses WPF.
[1] http://www.codeproject.com/Articles/859098/Sciter-multiplatf...
But in Sciter you can define even windows as HTML. Check this: http://sciter.com/images/sciter-clock.png, this is HTML and CSS[1]. Can you do that in browser or even in WPF?
I've also introduced <popup> element that allows to render DOM elements as popups outside HTML canvas (in separate windows) : http://terrainformatica.com/w3/sciter-tooltip.png
Yet all screenshots on http://sciter.com are HTML/CSS as they use Sciter for the UI. Essentially all AV vendors. Only Kaspersky AFAIK uses WPF.
[1] http://www.codeproject.com/Articles/859098/Sciter-multiplatf...
>Essentially all AV vendors.
Not sure that's an especially good thing to be proud of :>
Joking aside, I'm not sure I see your point with that clock. Windows with transparent elements? We've been able to do that for quite a while now. If you're referring to drawing that clock, I can use GDI on Windows and have the same result. With a bit of creativity you could probably have the hands rotate automatically with a binding, but my WPF is much too rusty for that.
Not sure that's an especially good thing to be proud of :>
Joking aside, I'm not sure I see your point with that clock. Windows with transparent elements? We've been able to do that for quite a while now. If you're referring to drawing that clock, I can use GDI on Windows and have the same result. With a bit of creativity you could probably have the hands rotate automatically with a binding, but my WPF is much too rusty for that.
"I can use GDI on Windows and have the same result."
Sorry but you should refresh your GDI knowledge (if it makes sense these days at all). You simply cannot render that with GDI. GDI does not know anything about a) antialiasing nor b) it knows anything about alpha-channel.
The only function that is available to you is ::AlphaBlend that is not even in GDI API but from msimg32.dll. And that function takes a bitmap. So you need some primitives to rasterize things like canvas.lineTo(point1, point2) with AA. And for GDI to do that on CPU side.
And CPU based rendering with modern 4K displays (Retina grade displays) makes no sense - on 192 DPI screen you need to produce 4 (four) times more pixels than on used to be standard 96 DPI displays. Our processors haven't grown that far in last 5-10 years. So forget about GDI, its time is over.
So if to think not just in yesterday's terms then the only option are GPU based renderers based on DirectX, Vulcan, Metal and OpenGL as a last resort.
Starting any projects today that relies on CPU based rasterization - pure waste of time - no present and no future.
Sorry but you should refresh your GDI knowledge (if it makes sense these days at all). You simply cannot render that with GDI. GDI does not know anything about a) antialiasing nor b) it knows anything about alpha-channel.
The only function that is available to you is ::AlphaBlend that is not even in GDI API but from msimg32.dll. And that function takes a bitmap. So you need some primitives to rasterize things like canvas.lineTo(point1, point2) with AA. And for GDI to do that on CPU side.
And CPU based rendering with modern 4K displays (Retina grade displays) makes no sense - on 192 DPI screen you need to produce 4 (four) times more pixels than on used to be standard 96 DPI displays. Our processors haven't grown that far in last 5-10 years. So forget about GDI, its time is over.
So if to think not just in yesterday's terms then the only option are GPU based renderers based on DirectX, Vulcan, Metal and OpenGL as a last resort.
Starting any projects today that relies on CPU based rasterization - pure waste of time - no present and no future.
It's sad. I wish Microsoft had improved and advanced GDI instead of starting anew with WPF (now Jupiter) such that we had a 2D UI toolkit suitable for the modern world instead of multiple competing, but only partially overlapping, frameworks (e.g. WPF is useless if you're doing native C++ and, but GDI lacks intuitive modern graphics features).
What strikes me is how Microsoft removed 2D hardware acceleration from GDI+ in Vista (wrecking performance, hence the shitty XOR operation framerate) and then introduced Direct2D without providing a clear upgrade path for developers.
What also sucks is that GDI and Win32 are so heavily intertwined it means that other frameworks (like WPF, Direct2D, etc) cannot integrate as well.
What strikes me is how Microsoft removed 2D hardware acceleration from GDI+ in Vista (wrecking performance, hence the shitty XOR operation framerate) and then introduced Direct2D without providing a clear upgrade path for developers.
What also sucks is that GDI and Win32 are so heavily intertwined it means that other frameworks (like WPF, Direct2D, etc) cannot integrate as well.
> I wish Microsoft had improved and advanced GDI instead of starting anew with WPF
The improved and advanced technology you’re describing is called GDI+. There’re things like anti-aliasing and alpha-blending implemented there. They work fine, but for compatibility reasons, it still renders on CPU.
Those years (mid-‘00s) there was a trend towards high-resolution displays, at that time it meant FullHD, driven by HD-DVD/BluRay. And a trend from desktops to laptops. It was already obvious GPU rendering was inevitable. The CPU and GPU are just fundamentally different. Hence the new GPU-centric technology.
> GDI and Win32 are so heavily intertwined
True, those two are coupled very tight.
There’s a good reason for that: performance. Win32 API largely based on Win16. And Windows 1.0 was running on systems like Intel 8088 4.77MHz, 640kB RAM. There wasn’t enough resources for better abstractions.
The improved and advanced technology you’re describing is called GDI+. There’re things like anti-aliasing and alpha-blending implemented there. They work fine, but for compatibility reasons, it still renders on CPU.
Those years (mid-‘00s) there was a trend towards high-resolution displays, at that time it meant FullHD, driven by HD-DVD/BluRay. And a trend from desktops to laptops. It was already obvious GPU rendering was inevitable. The CPU and GPU are just fundamentally different. Hence the new GPU-centric technology.
> GDI and Win32 are so heavily intertwined
True, those two are coupled very tight.
There’s a good reason for that: performance. Win32 API largely based on Win16. And Windows 1.0 was running on systems like Intel 8088 4.77MHz, 640kB RAM. There wasn’t enough resources for better abstractions.
GDI is an immediate mode graphics API that conceptually cannot be used with GPU style batch rendering. When each drawing operation is just a command record to be sent to GPU for later execution.
Yet things like GDI::SetROP2 make no sense in GPU context when rasterization is made in parallel. GDI uses integer coordinates - not that scaleable. GDI::COLOR type limits R,G,B by 0..255 values only... Too many problems.
But I shall admit that Direc2D API, that is C++ thing, could be made in more GDI-ish, plain C, style.
Yet things like GDI::SetROP2 make no sense in GPU context when rasterization is made in parallel. GDI uses integer coordinates - not that scaleable. GDI::COLOR type limits R,G,B by 0..255 values only... Too many problems.
But I shall admit that Direc2D API, that is C++ thing, could be made in more GDI-ish, plain C, style.
GDI is not a UI toolkit, though. It's a rendering API.
Direct2D is the replacement for that. I'm not sure what you mean by "multiple competing partially overlapping frameworks", because e.g. WPF is not it.
And, aside from WPF, which is really just lagging behind at this point, the rest of the Windows ecosystem is on D2D right now (e.g. UWP).
Direct2D is the replacement for that. I'm not sure what you mean by "multiple competing partially overlapping frameworks", because e.g. WPF is not it.
And, aside from WPF, which is really just lagging behind at this point, the rest of the Windows ecosystem is on D2D right now (e.g. UWP).
> WPF is useless if you're doing native C++
Not for those of us on Windows 8 onwards.
The way forward for C++ UIs is XAML, which is just the underlying foundation of WPF.
Not for those of us on Windows 8 onwards.
The way forward for C++ UIs is XAML, which is just the underlying foundation of WPF.
There is a pretty big difference between WPF, and the XAML UI Framework that you get in UWPs. When it comes to desktop apps, at least, WPF had a lot more features, and was generally more flexible and extensible. XAML UI is much closer to Silverlight, if anything.
When a new UI framework comes out, my test is: "Can Adobe build the next version of Photoshop with this?".
WinForms and WPF failed the test because they can only be run from within .NET applications. I was hopefull for Direct2D, but D2D is only a drawing API, there are no native widgets. XAML with C++ is nice in Windows 10, but I understand your application must run in the sandbox (for better and for worse) and when you use Win10 XAML you cannot use any UI code that uses any of the old-world code (e.g. Photoshop plugins). I'm also concerned that XAML prevents you from getting lower-level control over hardware (e.g. Deep-color support, hosting low-latency OpenGL contexts, etc). The sandbox requirement itself kills it for a lot of applications anyway.
Today, if you're writing a C/C++ program for Windows that needs to display a native Windows checkbox on screen (i.e. the Common Controls library or the raw Checkbox window class), and you want to customise how that checkbox is rendered, then you're still stuck with GDI - the WM_Paint message gives you access to s GDI device context in RAM - so you have to jump through hoops to use it with another 2D library or widget toolkit. How do I get an opaque handle to the window's texture surface in VRAM for ultra-fast painting or low-level control?
WinForms and WPF failed the test because they can only be run from within .NET applications. I was hopefull for Direct2D, but D2D is only a drawing API, there are no native widgets. XAML with C++ is nice in Windows 10, but I understand your application must run in the sandbox (for better and for worse) and when you use Win10 XAML you cannot use any UI code that uses any of the old-world code (e.g. Photoshop plugins). I'm also concerned that XAML prevents you from getting lower-level control over hardware (e.g. Deep-color support, hosting low-latency OpenGL contexts, etc). The sandbox requirement itself kills it for a lot of applications anyway.
Today, if you're writing a C/C++ program for Windows that needs to display a native Windows checkbox on screen (i.e. the Common Controls library or the raw Checkbox window class), and you want to customise how that checkbox is rendered, then you're still stuck with GDI - the WM_Paint message gives you access to s GDI device context in RAM - so you have to jump through hoops to use it with another 2D library or widget toolkit. How do I get an opaque handle to the window's texture surface in VRAM for ultra-fast painting or low-level control?
The future is sandboxed Windows, there is no way around it.
So while XAML with C++ does indeed require WinRT and sanboxing. That is where future Windows versions will be.
For high performance graphics there is DirectX and it interoperates perfectly fine with XAML. There are quite a few examples, including VS templates.
As for Win32, the Anniversary edition will bring the productified version of project Centennial, which allows running Win32 applications as sandboxed WinRT apps.
This is intended as a porting aid to bring Win32 apps into the new world, not as as something to use for new applications.
So while XAML with C++ does indeed require WinRT and sanboxing. That is where future Windows versions will be.
For high performance graphics there is DirectX and it interoperates perfectly fine with XAML. There are quite a few examples, including VS templates.
As for Win32, the Anniversary edition will bring the productified version of project Centennial, which allows running Win32 applications as sandboxed WinRT apps.
This is intended as a porting aid to bring Win32 apps into the new world, not as as something to use for new applications.
> and was generally more flexible and extensible
Depends on the direction where you’re extending them.
I’ve extended both WPF and XAML with 3D rendered content.
WPF still uses Direct3D 9 under the hood. Interop with modern D3D took some time to implement and debug: DXGI surface sharing is complicated, I remember hunting several bugs related to lost devices and concurrency.
Win8/XAML already uses Direct3D 11; interop with custom 3D content is painless, I don’t recall any issues.
Depends on the direction where you’re extending them.
I’ve extended both WPF and XAML with 3D rendered content.
WPF still uses Direct3D 9 under the hood. Interop with modern D3D took some time to implement and debug: DXGI surface sharing is complicated, I remember hunting several bugs related to lost devices and concurrency.
Win8/XAML already uses Direct3D 11; interop with custom 3D content is painless, I don’t recall any issues.
It might be, but that is where Windows on the desktop is headed, even Project Centennial is only intended as a means to bring existing applications into the new sandboxed world, not for greenfield applications.
So in the new WinRT world, C++ has a XAML stack and it is quite ok for me.
I seldom use the more powerful features from WPF that aren't in XAML.
So in the new WinRT world, C++ has a XAML stack and it is quite ok for me.
I seldom use the more powerful features from WPF that aren't in XAML.
The new WinRT world is not quite here yet - there will be a point when Win10 is so dominant that support for lower versions can be dropped, but that won't happen anytime soon; not with Win7 being as entrenched as it is.
So, for now, it's still WPF for most practical purposes on the Windows desktop. Indeed, that is even the case for Microsoft software - note how e.g. Visual Studio is still mostly a WPF app.
So, for now, it's still WPF for most practical purposes on the Windows desktop. Indeed, that is even the case for Microsoft software - note how e.g. Visual Studio is still mostly a WPF app.
Visual Studio is also a 32 bit application with no plans to ever upgrade to 64 bits unless forced otherwise.
https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting...
Should the OSDev stop doing 64 bit support, just because the VS team doesn't want to upgrade their tools?
The Office team is making use of WinRT.
As for Windows 7, it might be the new XP, but this time Microsoft is bullying the move into the new WinRT world, so lets see how long it will be around.
https://blogs.msdn.microsoft.com/ricom/2015/12/29/revisiting...
Should the OSDev stop doing 64 bit support, just because the VS team doesn't want to upgrade their tools?
The Office team is making use of WinRT.
As for Windows 7, it might be the new XP, but this time Microsoft is bullying the move into the new WinRT world, so lets see how long it will be around.
>>Essentially all AV vendors.
> Not sure that's an especially good thing to be proud of :>
Applications of that kind has quite strict requirements for performance, memory footprint, distribution size, incremental development of product that lives more than 10 years, etc.
Like this product: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on... survived transition from skeuomorphism to Metro style UI on the same code base. CSS rulez!
Applications of that kind has quite strict requirements for performance, memory footprint, distribution size, incremental development of product that lives more than 10 years, etc.
Like this product: http://sciter.com/from-skeuomorph-to-flat-ui-evolution-of-on... survived transition from skeuomorphism to Metro style UI on the same code base. CSS rulez!
Have you seen the things people have built with Electron? I wouldn't underestimate the capabilities of HTML/CSS/JS for desktop apps when you have projects like Slack, Atom, Visual Studio Code, GitKraken, the Brave browser, etc. all using Electron to build their desktop apps.
> Have you seen the things people have built with Electron?
Yes and they are slow, memory hungry and often crash for no reason. A javascript+HTML UI just can't compete with an app written in C# and WPF in term of performances.
Yes and they are slow, memory hungry and often crash for no reason. A javascript+HTML UI just can't compete with an app written in C# and WPF in term of performances.
They definitely feel clunkier to use though, if for nothing else but a noticeably less-responsive UI compared to apps using native controls etc.
Absolutely. My point is not from user's perspective here, but rather as a developer. WPF has its warts, but it's still a great framework specifically for desktop UI - because it was designed for that from ground up. Doing the same things in HTML/CSS/JS is definitely possible, but requires a great deal more effort.
If you want an analogy, it's kinda like writing web apps in C. Sure, you can do it, but there are much better tools.
If you want an analogy, it's kinda like writing web apps in C. Sure, you can do it, but there are much better tools.
Have you seen the things people have built with PHP? Or works of art made with chisels? :) Tooling can suck and be annoying to use, require enormous resources, etc., while still producing a result people like. We shouldn't confuse the two issues. The result is probably only relevant for true questions of "is it possible", as in "is it possible to write a fast-enough OS kernel in C#".
That's a table of various uninteresting factoids, not a comparison.
Does anyone have any war stories with Eto (https://github.com/picoe/Eto)?
It is a .NET cross platform toolkit similar in concept to Wx (it wraps native widgets).
It is a .NET cross platform toolkit similar in concept to Wx (it wraps native widgets).
I've been using Eto for a few years. It's amazing toolkit.
If anyone is working on cross-platform desktop app in C# which is meant to look "native" on each platform, then Eto is the best toolkit there is.
If anyone is working on cross-platform desktop app in C# which is meant to look "native" on each platform, then Eto is the best toolkit there is.
Yep, I agree - Eto is great for native controls! I consider Eto and Avalonia to complement each other rather than as competitors.
i tried using eto for a personal project, but i had to abandon it because i ran into a problem that i couldn't solve myself, and which got zero responses on the forum :(
https://groups.google.com/forum/#!topic/eto-forms/8tivDpoC3I...
https://groups.google.com/forum/#!topic/eto-forms/8tivDpoC3I...
Good work! .NET could use this right now from what I've come up with.
How could I work with F# on this? New to F# right now, and I would like to have a cross platform GUI. I have F# running on my iPad now (Continous App!).
How could I work with F# on this? New to F# right now, and I would like to have a cross platform GUI. I have F# running on my iPad now (Continous App!).
Looks great. I looked at it in the past but was put off by the GPL3 license attached to omnixaml. It looks to be MIT licensed now.
Avalon was the original codename for WPF. It is a great example of what you get when people vote on codenames.
Pardon my language, but fuck yea! Been waiting to see something like this happen
Wow, this could be the start of something big. Not often you see people working on desktop UIs anymore, and this of course being cross platform as well... definitely going to watch this one.
Looks great to me.
Looks great to me.
From contribution guide
> DO NOT USE #REGIONS full stop.
Why is that?
> DO NOT USE #REGIONS full stop.
Why is that?
Because I hate them.
EDIT: Ok, I'll explain :) : because when I open a file, I want to see the code, not folded regions telling me that it has constructors, properties, and methods. That's not interesting to me, it just obfuscates. There used to be an argument for using them for generated code, but partial classes are a much better choice for that.
#regions make me unreasonably irritated ;)
EDIT: Ok, I'll explain :) : because when I open a file, I want to see the code, not folded regions telling me that it has constructors, properties, and methods. That's not interesting to me, it just obfuscates. There used to be an argument for using them for generated code, but partial classes are a much better choice for that.
#regions make me unreasonably irritated ;)
[deleted]
Though this did have to hit front page when I'm doing a day of travel didn't it? :)