Though this did have to hit front page when I'm doing a day of travel didn't it? :)
I assume this is the relevant issue? https://github.com/AvaloniaUI/Avalonia/issues/314
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.
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.
I personally rather like YAML for anything intended for humans to read and edit.
What's funnier is seeing the HTTP/JSON folks re-invent SOAP. But maybe this time it'll actually be Simple.
Visual Studio Code handles this by just allowing comments in JSON used for configuration, heh.
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.
But this might change if a framework like Avalonia adds Core support.
However, I imagine our performance at the moment exclude use in games. It's something that needs to be optimized.
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/
But in Sciter you can define even windows as HTML. Check this: http://sciter.com/images/sciter-clock.png, this is HTML and CSS. 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.
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.
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.
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.
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.
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.
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).
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.
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?
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.
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.
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, 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.
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.
On the other hand, as far as UI frameworks go, VS offers a lot of flexibility - it's already a mashup, with some parts using native Win32 controls directly, some parts using WinForms, some parts using WPF, and some parts using HTML5. Basically, as new and better frameworks appeared, new parts of VS adopted them (and occasionally old parts would, as they got rewritten).
But there are no parts of VS that use WinRT (outside maybe of some stuff that relates to WinRT development). For a very obvious reason - there are too many users still on Win7.
BTW, did you know that VC++ guys still have to support the standard library on XP, because the users demand it? I don't mean old versions of it, but even the most recent releases...
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!
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.
It is a .NET cross platform toolkit similar in concept to Wx (it wraps native widgets).
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.
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 to me.
> DO NOT USE #REGIONS full stop.
Why is that?
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 ;)