Live data from Hacker News

Closing a 30 pixel gap between native and web

blogs.windows.com

61–70 of 313 posts

Re: Closing a 30 pixel gap between native and web

#61
post #58

Earlier quoted context omitted.

I don't disagree. It's for this kind of nonsense that I have "alt-space -> s -> down -> right" burned into my fingertips followed by moving the mouse cursor to resize a window deterministically (along with "alt-space -> m -> any arrow" for move, doubly useful to "rescue" an off screen window)

> 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.

Re: Closing a 30 pixel gap between native and web

#62
post #58

Earlier quoted context omitted.

I don't disagree. It's for this kind of nonsense that I have "alt-space -> s -> down -> right" burned into my fingertips followed by moving the mouse cursor to resize a window deterministically (along with "alt-space -> m -> any arrow" for move, doubly useful to "rescue" an off screen window)

> 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?

Works on windows for me. Also never really thought about this for rescuing a stuck window, I've always used winkey + arrow keys and kept mashing buttons until it appears on one of my monitors :P

Re: Closing a 30 pixel gap between native and web

#63
post #58

Earlier quoted context omitted.

I don't disagree. It's for this kind of nonsense that I have "alt-space -> s -> down -> right" burned into my fingertips followed by moving the mouse cursor to resize a window deterministically (along with "alt-space -> m -> any arrow" for move, doubly useful to "rescue" an off screen window)

> 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?

Default behavior for Windows applications (since 3.x, I think). Alt-Space brings up the Window menu.

Some odd-ball apps will replace it with their own menu, but few apps go to the effort to override the default shortcut it, even if they otherwise hide it.

Re: Closing a 30 pixel gap between native and web

#64
post #21
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…

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 different. However, and this may be an unpopular opinion, I don't want developers building an app that's meant to be used on a mobile device and a desktop. They're 2 separate ways of using a computer and they should be treated as such.

When I think of desktop apps like Photoshop, Outlook, Word, Chrome, and Da Vinci Resolve, they all look and behave very differently than their mobile counterparts (if they have one). If you want to develop for mobile and desktop, then you need to invest the time to make it a good experience on both. I hate desktop apps that have been mobile-ified to support mobile-first design. Design a proper UI and UX for the platform you're targeting. Otherwise don't bother "supporting" a platform you never test, intend to test, or design specifically for.

Re: Closing a 30 pixel gap between native and web

#65
post #64
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…

Porting a large-scale windows desktop app to linux takes engineer years.

Re: Closing a 30 pixel gap between native and web

#66
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…

> 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...

Re: Closing a 30 pixel gap between native and web

#67

Looks like the perfect place to fake some browser chrome and trick people... https://www.theregister.com/2017/01/19/browser_line_of_death...

That was my first thought as well, but I couldn't remember the name for that boundary. I hope there is a well-designed per-site control/setting/user consent system to keep tech support scam sites (or worse!) from adding one more tool to their arsenal.

I’ve seen it called “The Line of Death”

https://textslashplain.com/2017/01/14/the-line-of-death/

Re: Closing a 30 pixel gap between native and web

#68
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…

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.

Re: Closing a 30 pixel gap between native and web

#69
post #61
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.

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.

Re: Closing a 30 pixel gap between native and web

#70

Love how we're realizing that .hta was actually incredible. I have fond memories of building my own https://en.m.wikipedia.org/wiki/HTML_Application

Quick shout out to the Compiled HTML[0] (.chm) format for similar but unrelated reasons. The Help viewer application was one of the pinnacles of good UX, in my opinion.

[0]: https://en.wikipedia.org/wiki/Microsoft_Compiled_HTML_Help

Post reply on HN