Apple got it right with Cocoa (nee Nextstep) - it’s something they have been gradually building on with incremental improvements, continuously forwards and upwards - whereas Microsoft has been launching new, short-lived and incompatible (and incomplete) platforms for the past 15 years: WinForms, WPF, Silverlight, Jupiter (Win 8.1), UWP (Win10), etc. The story is so bad Microsoft’s own flagship software has to build their own UI frameworks (Office has its own, Windows Media Center had some arcane prototype of WPF, even the Windows 10 Start Menu uses some UI+Graphics framework that’s not exposed to third-party developers).
Win32 needs some serious work - not least because Win32 is “infected” with GDI which has its own issues. WinRT was nice but nowhere near sufficient.
I think this might be the other way round: if they're not eating their own dogfood, it's much easier for the UI framework to come adrift from actual use cases.
It's really telling that in Windows 8/10 they "modernised" some, but not all, of the control panel UI. It's basically random as to whether a setting you need will be in a Metro-flavoured window or a Win32-flavoured one.
To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications.
That's really infuriating. Makes me wonder what all these devs they have are doing the whole day.
"To me, the trouble with everything after WinForms is that it lacks a really compelling reason to upgrade. It's not easier to develop for and it's not nicer to use, and on many desktop systems the font rendering is much uglier in the new system. It does perform better at high DPI, but (catch-22) few people use high DPI windows systems because it's not well supported by even the OS let alone the applications. "
WPF had great potential and I think they could have made it a wonderful environment if they had kept improving it. Clean up XAML syntax (maybe something like they with ASP.NET and Razor) , simplify data binding syntax and debugging, make MVVM first class citizen and it would be great. Instead they (almost) stopped development of WPF and cranked out a series of half baked successors like WinRT, Silverlight and UWP.
For me the whole thing was cumbersome and nowhere near as productive as WinForms. Not only that but problems it purported to solve like high-dpi support still had issues.
I also wasn't a big fan of XAML - no matter how much time I spent using it, it mostly seemed more difficult and awkward to get components where you wanted them than with WinForms.
Never had any big problem that I can remember of since Visual Studio 2012.
> In fact, at a recent conference I was at with a large group of C# consultants. When the audience was polled on which desktop UIs their clients were using, the vast majority were WinForms, a small group was WPF, and almost no one was UWP
https://iamtimcorey.com/ask-tim-is-winforms-dead/
And many did long before WinForms
> Less than a year ago, a manager asked me if I could write a library for a client that would allow VB6 to access a RESTful API.
https://blog.submain.com/death-winforms-greatly-exaggerated/
That's true, but Apple also got behemoths like Adobe and Microsoft to port over their applications to modern APIs (Cocoa and Cocoa Touch).
Which is also a reason why they hardly have a meaningful market share across the enterprise world.
But in the real world when people talk about “mobile software” everyone knows that people are talking about iOS and Android. No one is chasing after the Windows software market, it’s been a diminishing platform for the past decade.
When they actually become a match to laptops and 2-1 convertibles, maybe.
And there Chromebooks are no where to be seen outside US school system, iPad Pros are mostly a gimmick in rich countries and Android 2-1 are basically phone apps with keyboard.
If I ever got back into desktop software, it would be highly specialized low level C/C++ code and not WPF/Sharepoint/UWP software.
I'm using AHGotoPage() because NSHelpManager has no equivalent and nobody has been able to explain to me how to make that class do a similar task reliably. (In hindsight, AppleHelp is such a disaster that I should have just avoided it entirely, as almost every other app does.) MAS reviewers have given me grief over many things my app does, but never any Carbon calls.
The last time I saw any Carbon APIs deprecated was 10.8, I think (6 years ago).
When working with Win32 it just isn't possible to avoid having to use GDI, for example dealing with painting to a window surface Win32 will give you a GDI device context by default - for example, similarly handling Win32 messages like WM_PAINT uses parts of the GDI API. Finally, each process on Windows has a limited number of GDI objects it can use as well. Oh, and using GDI/GDI+ in a service context (e.g. ASP.NET or a Windows Service, is not supported: https://blogs.msdn.microsoft.com/dsui_team/2013/04/16/using-...)
Direct2D is nice - but setting it up in your code isn't easy - and Microsoft does not maintain an up-to-date C#/.NET library for Direct2D.
They do for Direct2D on UWP, https://github.com/Microsoft/Win2D
The story is so bad because the Microsoft units making flagship desktop apps aren't productizing their UI frameworks (not suggesting that this is their choice), instead leaving the firm with public UI framework offerings not tightly grounded in that kind of use experience.
Good frameworks don't lead to internal flagship use, internal flagship use leads to good frameworks through tight feedback between real-world use and framework development.
That's the theme behind one of Joel Spolsky's old essays, Fire And Motion:
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
"Think of the history of data access strategies to come out of Microsoft. ODBC, RDO, DAO, ADO, OLEDB, now ADO.NET – All New! Are these technological imperatives? The result of an incompetent design group that needs to reinvent data access every goddamn year? (That’s probably it, actually.) But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft."
Win32 is a lower portability risk than UWP. Genuinely that’s what I’ve heard people say. Most of the UI and event stuff can be moved to wx or equivalent in a few months and deployed on other platforms.
UWP and you’re up shit creek.
Most companies are on the fence with running away from windows. It moved too fast, costs too much money to keep up with and has too much friction.
Take a look on the windows store for the massive uptake. Not. Half of it is still win32 and the rest is written by MSFT, crapware or abandoned.
Everything is in a right state despite the marketing to the contrary.
On one side it is a big reason why they have achieved their market size on the desktop, on the other side we reach this kind of situations where new tech improved tech like Singularity, Midori, Longhorn or now UWP gets thrown into the garbage can in the name of backwards compatibility. Quite sad.
Very few commercial products are able to drop Windows 7 support (and like, literally zero enterprise products can drop Windows 7 support).
So, no matter how nice UWP gets, most companies that would still be willing to write a native Windows app are 5+ years out from being allowed to adopt it, entirely because of how Microsoft chose to release it.
Might not be an issue in 5 years, by then MS will probably has a new new framework .
You would be suicidial if you based any product you want to sell to business on UWP. Not only doesn't it Win 7 or 8 but I don't see in what way UWP is better than WPF.
UWP is great if you are exclusively deploying to brand new Windows 10 Embedded devices. (I think this is now called "Windows IoT Core" or something similar). That's what I've been using it for, and that's worked well. It carries a nice side benefit that our sales team all has Windows 10 Pro laptops, and UWP 'just works' there too for sales demos, presentations, and such.
But I agree, selling UWP apps to businesses for traditional desktop use is ridiculously difficult.
> I don't see in what way UWP is better than WPF.
For a long time, UWP was the only way to get a working WebView (one based off of Edge instead of IE). But I think they fixed that and backported Edge to WPF a few months ago. (EDIT: they did kind of fix that - https://blogs.windows.com/msedgedev/2018/05/09/modern-webvie... )
This would be a great thing for us. But we already have a huge investment into WPF. How do we get this to UWP?
Now in face of this announcement, not sure.
Naturally this matters little to those enterprises doing plain CRUD applications with default L&F.
One big improvement in UWP is that Visual C++ finally merits the name Visual, although it still fails short of C++ Builder's RAD tooling.
And overall the sandbox model, however from the last Build it appears that Redstone will get an improved sandbox for Win32 apps as well, alongside MSIX support.
If Microsoft want's to move forward, they need to consider moving new stuff into WinForms and expand that with the features of UWP, WPF, XAML and other technologies they've tried to introduce over the years.
They could have done this 10-15 years ago. It's too late now.
Skype/Teams are developed in it and they have invested a lot of effort into TypeScript.
Maybe their secret plan is to push people into writing web apps with ASP.NET? Event that doesn't work because a lot of people will use Node instead.
Those customers were now thinking of eventually start moving into UWP after the Windows 10 migration was complete, so given this, they will continue using WPF.
Also Forms, WPF and EF 6 support are the major roadmap items for .NET Core 3.0
Node is no match against .NET or Java for those that care about performance.
http://doc.qt.io/qt-5/qml-qtquick-controls-treeview.html
http://doc.qt.io/qt-5/qml-qtquick-controls-tableview.html
Here are all the controls: http://doc.qt.io/qt-5/qmltypes.html
https://github.com/qmlnet/qmlnet
(I'm the author)