Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

Post reply on HN
Print view View original

121–130 of 313 posts

Re: Closing a 30 pixel gap between native and web

#121

Post by kllrnohj »

robocat wrote: post #97
kllrnohj wrote: post #55

Earlier quoted context omitted.

That won't meaningfully change performance at all. Browsers aren't slow because they have to make slow syscalls - they mostly don't. They are slow because web technologies themselves are slow, sometimes by design, sometimes because of security/abuse concerns, but often just because HTML & CSS are absolutely crap platform for interactive UIs, something they were never intended to be and retrofitting that doesn't resul…

> HTML & CSS are absolutely crap platform for interactive UIs I mostly disagree. HTML is great for plain forms, that seamlessly work at different form-factors (from mobile to desktop) with very little work. Browsers are also good at graphical outputs. Browsers can fall down when you need rich, complex, or custom inputs: because virtual keyboards are very different from real keyboards (iOS especially poor), and touch…

> HTML is great for plain forms

I'm not sure I'd call that an "interactive UI" though as that's pretty much a static layout. Which yes HTML is fine at handling.

> Browsers are also good at graphical outputs.

They're okay graphical outputs, not good ones. The feature sets are good, but the performance is all over the place and pretty much always sub-par as they are very defensive against content. Meaning the difference between the fast path (so plain scrolling) and the "slow" path (nearly anything else) is absolutely massive. Even things that are all but free on native toolkits, like just animating a color, can tank browser performance.

> But we go where the users are

Of course, which is mobile apps ;)

No but the point is just browsers aren't slow because they are an OS inside an OS. The layering isn't the cause of really any problems other than the binary size of the browser itself.

Re: Closing a 30 pixel gap between native and web

#122

Post by fragmede »

com2kid wrote: post #83
smegsicle wrote: post #66

Earlier quoted context omitted.

> The title bar area is meant for users to move the Window around i thought that's what alt-drag was for? maybe microsoft didn't get that memo either...

The most basic of window operations shouldn't require a hotkey. Rearranging windows on MacOS and Windows now requires video game precision aiming. It is absurd. What's more, every app places things in different parts of the title bar, so I have to search for "where to click" based on which app window is up. Absurd. The move to controls in the title bar is absurd. It used to be Windows had standard chrome, title bar,…

The most basic of window operations wants to be bound to a hotkey because it's a basic window operation and there should be easy and quick access to it. Linux does this by default and I find it's an indispensable feature.

To get it on Windows search for AltDrag.

Re: Closing a 30 pixel gap between native and web

#123

Post by david2ndaccount »

Arainach wrote: post #112

Alternative title: now your web apps, just like your native apps, can have unpredictable drag/resize/snap/double click to maximize behavior! Ugh. I wish apps would leave reusable consistent system UI elements alone. Has Adobe gotten around to making their title bars DPI-aware yet? Every app that tries this gets at least something wrong. Let's take a look on a random sampling of native-ish Windows apps: Discord (Elect…

Chrome hides the app-icon in the top-left which breaks my muscle memory.

Re: Closing a 30 pixel gap between native and web

#124

Post by bentcorner »

sedatk wrote: post #60
wolpoli wrote: 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…

Yeah Microsoft Word is terrible in that aspect. You don't even need to make the window too narrow. https://twitter.com/esesci/status/1414631138379792384

FWIW you can still click+drag on the file name/search bar. Not as intuitive but it's a big target that you can still use.

Re: Closing a 30 pixel gap between native and web

#125

Post by MereInterest »

david2ndaccount wrote: post #84
wolpoli wrote: 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.

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.

Re: Closing a 30 pixel gap between native and web

#126

Post by p1necone »

dejawu wrote: post #108
p1necone wrote: post #100

Earlier quoted context omitted.

I much prefer what a lot of Linux desktop environments support, which is holding down alt and clicking anywhere on a window to move it. With that + a keyboard shortcut for closing a window you can get rid of title bars on apps entirely if you want. Sadly Windows doesn't support it natively, although there's another comment on this thread talking about ways to make it work.

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.

Re: Closing a 30 pixel gap between native and web

#127

Post by LASR »

_gabe_ wrote: post #64
loudmax wrote: post #21

Earlier quoted context omitted.

The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer. The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.

I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me. Now, I've never ported an app to mobile, and that may be entirely diff…

> ported a game

Most of the immediate pain with native to native ports is shift between UI frameworks. This always requires a huge investment to do correctly.

Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.

Simply changing your compiler target is easy. This is not what people are complaining about obviously.

Re: Closing a 30 pixel gap between native and web

#128

Post by rifty »

This is a bit peripheral to the link but I had a thought. As PWA's get further integrated, I feel like this leads to eventually shifting people off of the Web Browser. In this case over into the Microsoft Browser... i mean the Microsoft Store. I guess, what is the difference to Microsoft between the windows engine, the web engine, or the java engine as long as it is able to serve user applications and they are still able to leverage out a cut from it? With the advent of internet payment processing and non-transferable purchase information the store is as good as the the OS was in terms of lock-in. The store over time becomes the target platform for dev's instead of the OS.

Re: Closing a 30 pixel gap between native and web

#129

Post by quotemstr »

drekipus wrote: post #69
sedatk wrote: post #61

Earlier quoted context omitted.

Alt-space menu is Windows specific IIRC.

Gnome does the same, I use it all the time for "pin window always on top" Which windows still doesn't have, for some reason.

Gnome doesn't have menu accelerators in the window menu though, so "alt-spc n" does nothing: the alt-spc brings up the window menu, but the n doesn't activate "minimize". This interaction not functioning in Gnome keeps me off Gnome entirely.

Re: Closing a 30 pixel gap between native and web

#130

Post by opan »

sedatk wrote: post #61
jolmg wrote: post #58

Earlier quoted context omitted.

> alt-space -> s -> down -> right > alt-space -> m -> any arrow Are those keybindings default on a particular OS/DE/WM/WC or are they just your personal config?

Alt-space menu is Windows specific IIRC.

I think openbox uses it as well.
Post reply on HN