3 ms·

> ability to create their own title bar experiences It was a sad day, IMHO, in UX-world when this became possible in desktop apps. The window system should own

> ability to create their own title bar experiences It was a sad day, IMHO, in UX-world when this became possible in desktop apps. The window system should own the chrome and the apps should not be able to touch it.

jonathankoren 4y ago
Looking forward to the day when Winamp style apps are back. Remember round windows? They’re back, in Electron form.
postalrat 4y ago
They still do. https://blogs.windows.com/wp-content/uploads/prod/sites/33/2022/09/Picture2.png https://blogs.windows.com/wp-content/uploads/prod/sites/33/2... Didn't that picture make it obvious?
- Arainach 4y ago
  Now a single app bug can make it so you can't drag a window. Oops, we accept clicks everywhere and never fall back to whatever the web equivalent of DefWndProc is, I guess it's all app space and no actual title bar in that blue.
  - contextfree 4y ago
    Win32 apps have always been able to break dragging, since ultimately the app process "owns" the window frame and can hang and block all interactions with it. (The system tries to catch simple cases of hanging where the app obviously isn't processing messages, but that doesn't cover all situations) Actually, UWP sort of solved/solves this, by having a different process own the window frame.