Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

131–140 of 313 posts

Re: Closing a 30 pixel gap between native and web

#131
post #44

I actually wish programs do not put content in the Title bar area. The title bar area is meant for users to move the Window around. Try opening Microsoft Word, make the window narrow and drag the window. You have to hunt for a small bit of empty space in the title bar or you have to understand you could drag on the Title text, Search box and the Sign in Username, but not the Auto Save text, Upcoming Features icon, or…

For moving things around across monitors & snipping them to specific half of desktop I personally use Winkey+[shift]+arrows shortcuts, I recommend you check it out if you haven't already! I honestly don't remember when was the last time I needed a window with custom size. Maybe when placing 2 windows side by side? But even then, the OS recognizes that I want to see 2 windows at the same time and adjust sizes of both windows...

Re: Closing a 30 pixel gap between native and web

#132
post #68

Earlier quoted context omitted.

When you see decades of Windows version after Windows version, each billing itself as "the fastest Windows ever!" and each having higher minimum system requirements than its predecessor, two conclusions are inescapable: 1. The Redmond wizards have devised a method to make software run faster and all it requires is faster hardware. 2. Microsoft is in bed with hardware manufacturers.

What are you talking about? I'm running Windows 10 on a 2009 computer - one which was low-mid end back then. Only upgrade is an SSD.

The system requirements are something they put out on paper, parent isn't necessarily saying you need a better PC, just saying Microsoft themselves say that, which you can verify yourself.

Re: Closing a 30 pixel gap between native and web

#133

Earlier quoted context omitted.

> I think web is taking over on Windows because any of 10 or 15 different design systems can get you to a better app than the native (whatever that means) toolkits in much less time. It is easier to get a decent color picker in a web app than a WPF, WinForms, UWP, WinUI, or Win32 app (assuming you have a reasonably high expectation for UI/UX, as I do). I'll grant you that it's probably easier and cheaper to get a wor…

The word “cheaper” here is doing a lot of work. Yes, it’s cheaper, meaning that it allows you to ship more stuff faster. You could make the argument that this results in lower quality, but this isn’t always the case. (For example, VS Code feels great!) Still, I’d often rather have twice the features at 80% the quality, instead of an extremely high quality product that doesn’t have the features I need. Cheapness leads…

We're taking about a trillion dollar company who can afford all of the talent and has very limited time pressure. I would prefer they do it correctly.

Re: Closing a 30 pixel gap between native and web

#134
post #44

I actually wish programs do not put content in the Title bar area. The title bar area is meant for users to move the Window around. Try opening Microsoft Word, make the window narrow and drag the window. You have to hunt for a small bit of empty space in the title bar or you have to understand you could drag on the Title text, Search box and the Sign in Username, but not the Auto Save text, Upcoming Features icon, or…

I also dislike how apps are now disabling the classic win32 app icon in the top left corner. If you click on it, you get a menu with window management options and double clicking it closes the window. It’s so burned into my muscle memory as the way to close a window I get frustrated when apps hide it.

Oh god, I thought I was the only one.

Re: Closing a 30 pixel gap between native and web

#135
post #108

Earlier quoted context omitted.

I love this feature and it's since become indispensable to me. I find it pretty funny that my #1 favorite desktop UI feature is from Linux. One of the first things I'll put on a fresh install of Windows or MacOS is a utility that re-creates this behavior. I use AltDrag on Windows (requires a quick tweak for HiDPI): https://stefansundin.github.io/altdrag/ And Easy Move + Resize on MacOS: https://github.com/dmarcotte/e…

I'm hoping that Microsoft just implements it natively eventually - their window snapping/tiling-lite functionality has been steadily getting better so they clearly have people working on this kind of window UX QOL stuff.

There's a Microsoft utility calls powertoys that makes the window snapping/tiling even better with it's Fancy Zones feature. Also has a color picker which someone in this thread was decrying the lack of on windows.

https://learn.microsoft.com/en-us/windows/powertoys/

Re: Closing a 30 pixel gap between native and web

#136
post #12

I think this is a sign that Microsoft sees the writing on the wall. There will be a day when Windows is left behind, and they want to make sure that they can continue to deliver the Microsoft experience, even on other platforms.

I don’t think Windows is ever going to be left behind, you still need a kernel to make use of all your hardware and an OS to give users something to do. I view this move as Microsoft recognizing that the future of most development is cross-platform web technologies and they need to give Windows users reasons not to migrate to macOS and ChromeOS (though it’s ok if they do as long as they’re paying for O365 and Azure).

Windows isn't the only kernel and it's not a huge part of Micrsofts revenue

Re: Closing a 30 pixel gap between native and web

#137

Earlier quoted context omitted.

I also dislike how apps are now disabling the classic win32 app icon in the top left corner. If you click on it, you get a menu with window management options and double clicking it closes the window. It’s so burned into my muscle memory as the way to close a window I get frustrated when apps hide it.

About 15 years ago, I remember being aghast at Skype hijacking the X in the top-right, minimizing itself to the taskbar instead of either exiting or minimizing to the system tray. Because there was a clear standard action that was intended by that interaction, and Skype had gone out of its way to override that standard action.

Wait till you find out how Windows has hijacked "Shut down the computer"...

Re: Closing a 30 pixel gap between native and web

#138
post #15
post #6

With all this Electron and PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system, that could be avoided. An extra layer which occupies RAM space and processor time which feels unnecessary but it is where we are headed. I wonder if the reason is simple, that we (myself included) have not provided anything better or the reason is that big corporations w…

This. I encountered hell the other day. I saw a corporate Citrix deployment that had 45 users running three electron apps on an underprovisioned server with the CPU, disk and memory rammed at 100% lagging out. That’s 135 separate browser stacks basically. Microsoft are moving office to this stack as well. Ugh. Of course I was there trying to work out why our simple old fashioned web app was running slowly in a chrome…

Our hospital system uses Citrix and the application patients have to sign in with runs on some web framework instead of being a native Windows app. Such a frustrating experience using the on-screen keyboard to enter your name to sign in.

Re: Closing a 30 pixel gap between native and web

#139
post #88

Earlier quoted context omitted.

A lot of developers are not fans of Electron. Generally, it's a quality vs quantity tradeoff. Are you willing to make a crappier thing if it means more people can use it? For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.

> For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user. Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up. While I am sure the Windows org had lots of them,…

>> I imagine native MacOS developers are similarly rare as a % of the overall developer pool

Which is a shame, because as bad as Xcode is, developing native apps on the Mac is almost pleasurable compared to Windows or Linux

Re: Closing a 30 pixel gap between native and web

#140

Earlier quoted context omitted.

They still do. https://blogs.windows.com/wp-content/uploads/prod/sites/33/2... Didn't that picture make it obvious?

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.

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.

Post reply on HN