So I tried using the old GUI framework and boy was it a nightmare to customize anything. I remember having to override the default Button class and add like 50 lines of code just so I could get a custom background. This and the fact that C# back then couldn't do high scalability servers were what forced me to learn C++ and in my opinion QT is a much easier library to use than the old WinForms was.
Since WinForms' existing styling was the style of applications of the day, there was little reason to heavily restyle it. Honestly, if someone ran with the new open source WinForms and introduced a Windows 10 style that I could build with the same incredibly easy editor as the existing WinForms, I'd be set.
That's mostly because you're not supposed to be doing that sort of thing in the first place. Customizing widgets = inconsistent look and feel. Custom widgets = Inconsistent LAF, inconsistent interaction, no accessibility etc.
The idea of Win32 UI, WinForms etc. is that you have a look and feel dictated by the system, not by individual app developers, with the ultimate goal being not just a consistent look and feel of the whole system (including applications) but consistently applied patterns of interaction. This in turn makes computers easier to use.
Of course, modern UI frameworks, whether in the browser (JS) or outside the browser (QML, UWP, JS, ...) run completely counter to that.
I was trying to write a poker client so same thing, using normal buttons just wouldn't have made any sense. It would've been ugly as hell.
Modern UIs stray from a standard because standards are boring and if your app is boring then your not so boring competitor will snatch your users.
I actively judge apps with non-platform-standard UIs as worse than an equivalent with a standard UI.
That covers about 90% of Hollywood's output, and the reason for that is that you want a wide audience to purchase tickets. Only people that are good at navigating new interfaces appreciate novelty. That's a niche audience, but it intersects with the gamer audience (they're good at exploring new environments).
There are enough exceptions that whatever API you are using should accomodate developers in those cases. If people want custom UIs they'll get them somehow, you putting unnecessary roadblocks in the way will only annoy developers.
Managers don't care how you do it, they just want it done.
That's because the underlying widget set is as ugly as hell.
Ohh, the good old days...
That always puzzled me, even though I've seen some of Microsoft's reasoning and blog posts about it.
Microsoft has repeatedly stressed that you can't assume any particular version of Windows comes with a specific version of .NET preinstalled (or VC++ runtime, for that matter).
Windows already bundles various things, and the major .NET frameworks seem like the thing to bundle and preinstall, and they actually do[0], just not consistently or universally.
And, Windows Update can already update the .NET frameworks, in fact I recall that some new major .NET versions were treated as "recommended" installs by WU in the past and were automatically installed on systems that didn't already have them, but they aren't doing that consistently and universally either.
[0] https://blogs.msdn.microsoft.com/astebner/2007/03/14/mailbag...
Of course, that is a system-level change, which can potentially break other applications on your machine (if they're written badly and/or poorly supported). .NET Core removes that by supporting side-by-side versions and versions packaged with the app, but it certainly wasn't critical to assume a given machine already had a .NET Framework version in question.
Honestly, with Windows 10 now including .NET Framework updates along with feature upgrades every six months, and the fact that pre-Windows 10 versions of Windows haven't that many more years to live, it feels like that advantage isn't as big as it used to be anyways.
My concern is .NET Core may lead to a lot of unnecessary software bloat. Where Windows has the current .NET Framework, but we still have to have six versions of .NET Core installed, and then half the programs on the computer don't use those and have their own bundled versions as well. I find .NET Framework already being on-system to be a big perk of writing my app with it: My software is a 7 MB file because most of the code is already built into Windows.
I think Lazarus[0] is easier, especially when it comes to automatic layout stuff, but WinForms is very close. They're somewhat related as both are descendants of the classic Visual Basic RAD approach and Lazarus is basically an open source and cross platform clone of Delphi while WinForms implements a very VCL-like (VCL is Delphi's framework) API - which is natural since both Delphi and WinForms were designed by the same person :-P.
Beyond the above (which i think are all what WinForms provide, at least from the visual designer) the anchors can also be set so that instead of just "sticking" to a designed edge, they are set relative to some other control in the parent container with customizable gaps. For example you can configure (using a dedicated anchor editor window) that the left edge of an input box is 5 pixels away from the right side of the label control and the label control's top edge is aligned so that the label's center matches the edit box's center. Note that any control can be anchored to any other control, so if you have a form with 10 input fields you can anchor their left side to the same control (e.g. the longest label or a "guide" control) so that they align neatly.
The align property is enough for most cases and the anchor system covers almost the rest of the layout cases. Where those do not suffice, there are a few more dedicated options like the TFlowPanel container that flows controls in various formations as well as the ChildSizing property that allows for specifying some automatic layouts. TBH personaly i never had to use those though. Note that most of them can also be combined.
Finally each control also has constraints (min/max size) and spacing (margins) for each edge as well as an overall spacing.
Somewhat related, but you can also make pretty much any control dockable by setting its DragKind property to dock and DockMode property to automatic. Docking happens in "dock sites" which are basically any container (like a panel) that has its DockSite property set to true (and preferably, although not required, its AutoSize also to true) and since containers are regular controls they themselves can be laid out using any of the above options or be anchor targets for sibling controls. The framework handles the whole drag/drop, docksite resizing, creating popup windows for tearoff docks, etc. In fact the whole docking system is modular itself and there are a couple of different docking managers that provide quite advanced options.
Note that all i've mentioned so far are done with the visual designer, there is obviously more fine grained control by writing code.
The stuff with anchors being relative to other controls, though, sounds like it should be roughly equivalent to Java GroupLayout in expressive power. Which is neat!