Microsoft emits Preview 3 of next-gen WinUI framework, says Linux support 'is not off our roadmap' Microsoft has released Preview 3 of WinUI 3, its next-generation framework for Windows desktop applications. Those still trying to keep track of Microsoft’s plans with regard to Windows desktop development were given some new insights in the latest preview of WinUI 3 and an associated community standup with Kevin Gallo, corp …
Damn boy, what sort of lightning do you have where you live?
I can frequently type well ahead of Slack and Google Docs, and I'm not that fast. An article on Medium locks up my tablet for several seconds. Many (many) web pages keep me waiting until I decide I don't care that much after all.
No, none of my computers are slow. Multi cores running at multiple ghz (the only other time 'multiple' is a good thing) should not make me wait unless I'm handling sodding huge data sets. Since I don't edit feature length movies in 4k nothing should take more than an eye blink.
I'll have native executables, thank you. And profile to optimise first.
From my armchair perspective it seems MS brings out yet another UI framework every other year. Why? The WIMP interface is a solved problem, any WIMP API should be rock solid and stable now with any additions simply being interfaces to more GPU functionality. HTML/XAML/whatever processing and display should be a higher level API, not mixed in with the UI API.
It comes quite late in the article, Joel Spolsky explains pretty well.
The WIMP interface is a solved problem
In principle, but not in practice.
There have been a number of reasons to revisit implementations. One is the advent of the mobile phone/tablet that not only has a much less precise pointer (the human finger) but also a significantly different resolution to the traditional computer screen (originally much less, latterly much more). Some of the assumptions built into original WIMP APIs are not great under those circumstances, especially if you want your application to work reasonably well across a range of screen sizes and resolutions.
Another is the advent of the GPU. When you're no longer directly drawing to a bitmap you might need to construct your API differently so it's clearer which objects can be rendered by the GPU later.
And a third is network transparency. That's particularly hard because it's difficult to predict how future technology might change assumptions about how the balance of work should be divided between client and server, but you can't easily add it later without possibly undermining the assumptions you might already have made in your local API.
And that's just the graphics primitives. When you come to high-level features such as checkboxes, buttons and text layout, the web stuck its oar in by doing things differently and we've been in search of convergence with desktop applications ever since.
But apart from that it's largely solved. In 2D. For now.
I'll give you the tablet issue, but the rest of it should just be hidden. The back end should worry about using/not using the GPU and network transparency which no change to the API required. This is exactly how X windows was designed and that was back in the 80s, there's really no excuse for it not being the case in 2020 especially when RDP et al have been around for Windows for decades.
I've thought, if Microsoft wanted to lend some "legitimacy" to the "universal" in UWP, they should port runtimes to Linux and MacOS (and maybe the various BSDs while they're at it).
Of course, if the runtime were made as open-source, it would also be amusing to see it ported to the various AmigaOS derivatives, though I doubt an original Amiga could handle the resources it would demand.
The original Amiga dealt with it quite well, almost entirely relying on it's native to ROM routines and custom chips.Sticking to those techniques and taking advantage of clock increases since, I'm damned certain it would eat Window's lunch. I know that system cold and used to spend a lot of time talking to the hardware architect almost daily, Jay Miner.
The problem is on Microsoft's end. Amiga was quite parsimonious with resources which is why most of Amiga programming consisted of building structs and tossing them at Intuition and AmigaDOS.
While such a reaction is understandable, a coherent windowing system instead of multiple forks and dependency hell would make writing applications for linux rather easier... I am less keen on MS being the force behind it, though, if the internals of such a framework are themselves open rather than binary blobs it is a promising place to start.
I remain paranoid of the embrace / engulf / exterminate history that MS can not escape. Demonstrate morals and values and maybe, just maybe you can persuade the cynics like me that times have changed.
This doesn't really enamour me to developing Windows applications, to be honest. I might as well develop in Python and use Tkinter as the GUI engine - the same code will run anywhere. Okay, so it might be as flashy, but at least I know I can continue to deploy my app years into the future and it'll 'just work'. Seems there's no such guarantee with Windows any more. Why? Why so many GUI implementations? Why introduce GUI dependencies? It used to be (in Windows) that you drew your GUI, filled in it's properties and events and you were done. I don't do Windows dev for a long time, but sounds like we've moved a long way away from that. Why? What a mess.
Unfortunately this is the response of a lot of developers and is why there are so many appallingly mismatched user interfaces out there. Quite understandable of course.
Microsoft used to have a very good and well thought out and reasoned user interface style guide for windows applications. Unfortunately it got shredded, set on fire and thrown out around the time they vomitted out Windows Vista as this utterly useless GUI was counter to pretty much every good UI design paradigm out there.
Naturally, some parts of Microsoft adhered to the guide more than others. For example, Microsoft AutoRoute never adhered to anything at all and with Microsoft insisting that every new iteration of Microsoft Office used the GUI of the latest operating system rather than the GUI and look/feel of the installed operating system they recreated huge swathes of the OS UI within their applications. Made more ridiculous because windows XP "skins" were an appalling hack overdrawing previously drawn components. Around this time Microsoft developers also saw the "wasted space" of the title bar and decided to start pissing around adding custom GUI components into this, with other applications following suit because they couldn't be seen to be inefficient with space compared to Microsoft Office. Since then, GUI rendering has been a precarious thing as anyone running multiple monitors tends to find with random ghost parts of the top of the screen becoming unusable... not as frequent as it used to be, but still happens regularly.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
