491–500 of 604 posts
I got to the point that I could create windows and controls, and had a basic message loop working.
I then started dabbling in painting in non-client areas. It was buggy and didn't work well (my fault), but then I could see 2-3 different Windows UI styles competing to draw the window chrome.
The amount of crumbs hidden under the Windows carpet is incredible.
Earlier quoted context omitted.
>i.e. dissuaded from using native, but rather bespoke, UI frameworks. Based on my experience, I would be quite reluctant to rely on any non-native cross-platform desktop UI framework that is not web-based. These tend to be either less performant, look outdated or are bug-ridden.
What about Qt? It is the gold standard for cross-platform desktop UI frameworks. It is (1) performant (C++-based), (2) does not look outdated, and (3) not bug-ridden.
Developing UIs without hot reloading is too painful.
What I find must puzzling is that everyone seems to just be violating basic rules that had been in place for ages. Things like: - If you can't respond to a UI event wait until you can - Menus should be tree structures - Pressing alt should underline the hotkeys you need to access anything clickable As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may…
It's because we went from the Desktop environment, where rules were well-documented and standardized, to the Web/Mobile environment, where rules had to be reinvented and, for the most part, were not. We've lost design idioms , which is a huge tax on users everywhere. I've been mad about this for years: https://essays.johnloeber.com/p/4-bring-back-idiomatic-desig...
I personally love dense UIs and have no expectation of doing certain kinds of work on a phone or low-powered device like a chromebook, phone, or bottom-barrel laptop. But if you're a company trying to sell products to a broad user base, you want to try to design in a way that works for those kinds of users because they still might be end-users of your product. And there's a good chance that those platforms may be where someone first evaluates your product (eg from a link shared and accessed on a mobile device) even for the users who do plan on using more powerful desktop devices to do their work.
So instead we get these information poor, incoherent (because it turns out proper cross-platform, cross-user design is much more difficult than just getting something that works cross-platform for all users on its surface) interfaces. I guess I'm writing this just to add, web/mobile have complicated things partially because more than just requiring their own distinct patterns, they each represent a distinct medium that products try to target with the same kind of design. But because they're different mediums, it's like trying to square a circle.
Earlier quoted context omitted.
It has been associated with 3D rendering, but given that things like the S3 86C911 are listed on the Wikipedia GPU page, saying "Accelerated GUIs don't need GPU" feels like attempting to win an argument by insisting on a term definition that is significantly divergent from standard vulgar usage [1], which doesn't provide any insight to the problem originally being discussed. [1] Maybe I've just been blindly ignorant…
I don’t agree with what you state as the vulgar usage. “Graphics card” was the standard term a long time, even after they generally carried a (3D) GPU. Maybe up to around 2010 or so? There was no time when you had 2D-only graphics cards being called GPUs, and you didn’t consciously buy a discrete GPU if you weren’t interested in (3D) games or similar applications. In the context of the discussion, the point is that y…
Earlier quoted context omitted.
What about Qt? It is the gold standard for cross-platform desktop UI frameworks. It is (1) performant (C++-based), (2) does not look outdated, and (3) not bug-ridden.
I think Qt is only missing well-written, feature-complete bindings for a major JS runtime, including support for hot reload. Developing UIs without hot reloading is too painful.
Earlier quoted context omitted.
What about Qt? It is the gold standard for cross-platform desktop UI frameworks. It is (1) performant (C++-based), (2) does not look outdated, and (3) not bug-ridden.
In my experience: - Qt Widgets worked fine, but looked like a piece of software made in 2013; - QML looks stylish and is a very nice language, but had a lot of weird bugs. Neither of these are issues I'd run with if I were to make a web app.
Earlier quoted context omitted.
That might have been more significant had the Windows Runtime not been effectively locked off to Metro-style apps. You could technically use it from a desktop app, but almost all of its functionality was only allowed within a Metro-style app, often due to requiring a core window or package identity. Even today the vast majority of useful WinRT APIs, including the entire UI system, require UWP or package identity.
Package Identity isn't that different from Signed COM Registration of the ancient past. Microsoft built up a lot of dislike from it by building it "sandbox-first", but the core of it still isn't that different from COM's ancient footpaths, at least to the COM diehards that hate .NET and didn't learn near enough from .NET's battles with the same things in terms of package signing, CAS (Code Access Security), and the G…
For example, Windows classic desktop apps still have no equivalent to the UWP app lifecycle. Your UWP app's processes can be suspended and resumed without you writing code to force the suspension and request when to be resumed later. Instead, you are expected to appropriately handle event notifications for suspend, resume, and the app entering and leaving background state.
This system-managed UWP app lifecycle makes life harder for UWP app authors, but I think the net win for battery life is much better for the user experience, which is why mobile apps operate the same way. Yet the docs for the Windows App SDK, which is supposed to bring the best of the UWP to desktop apps, explicitly say that WinAppSDK apps control their lifecycle just like other desktop apps, and the only power friendliness in the WinAppSDK API is voluntary (aka no one will use it). [1, 2]
I'll probably write more soon in response to other parts of the original link's comment thread. Overall, I feel like UWP is being unfairly maligned here, and that while its introduction was unforgivably arrogant, Steven Sinofsky is also right that it was daring and necessary to fix the mistakes and outdated decisions of 16-bit Windows and Win32.
[1] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...
[2] https://learn.microsoft.com/windows/apps/windows-app-sdk/app...
What I find must puzzling is that everyone seems to just be violating basic rules that had been in place for ages. Things like: - If you can't respond to a UI event wait until you can - Menus should be tree structures - Pressing alt should underline the hotkeys you need to access anything clickable As well as just basic responsiveness or predictability. A 2000 era windows application may not have been pretty, and may…
Steven Sinofsky wrote this piece a couple of weeks ago about the same topic: https://x.com/stevesi/status/2036921223150440542
It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off. I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent o…
I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs and how it has made Windows' developer platform much worse over the years, but I have always thought we had a better relationship than that, since my group's product was the main reason for yours for many years, and your group delivered so much for us in turn. Clearly your side had at least some reason to see things differently. On behalf of all of us, yes even up to stevesi, I'm sorry.
Now let me completely undermine my apology by nitpicking your comment :)
[continued in my replies to this comment]
Earlier quoted context omitted.
It's very amusing to see Sinofsky of all people all but dumping on .NET and (still?!) not understanding why developers so proactively jumped ship from Win32 & MFC hell to WinForms. Or why the HTML/JS app model in Win8 never really took off. I was in DevDiv during his great WinRT push and the overall feeling I remember was that the guys in Windows had zero clue as to what the devs actually wanted, but were hell bent o…
(disclaimer: I was an individual engineer in the Windows division during the Windows 8 project, i.e. reporting through Steven Sinofksy) I think you're being a bit unfair to the Windows division during the Win8 lifecycle. Maybe that's just my rose-tinted glasses though. I know there are some HN/proggit commenters who like to harp on the supposed toxic rivalry between the Windows orgs and Microsoft developer tools orgs…
At the risk of getting my Microsoft history wrong, I'm fairly sure that Steven Sinofsky wasn't working on Windows or even MFC (i.e. what he did as one of you guys) in .NET's early days of 1999-2003. He was leading Office at that time. Office of that era was transitioning from the Windows XP look that still persists in Windows Forms to the early Ribbon, and was then (as now?) using very custom GUI code that didn't correspond to any specific higher-level Windows app framework.
Mac OS Office apps had just separated their codebase again from Windows apps after being unified in the mid-90s to get to feature parity (which annoyed Mac users who felt they now had non-native-feeling apps that were slow and bloated), and the "Office framework" was still quite distinct from any single-platform Windows app as a result of that.
So if Sinofsky did not understand why people went from USER/GDI to WinForms, that may just have been the fact that nobody working for him had felt the need to make that transition.