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

241–250 of 313 posts

Re: Closing a 30 pixel gap between native and web

#241

Post by austhrow743 »

lelanthran wrote: post #207
muspimerol wrote: post #200

Earlier quoted context omitted.

When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS.

> When is the last time you used CSS? "How to center a div" has not been an issue with CSS for many, many years. Flexbox and now CSS Grid have overwhelming adoption and most layouts can be achieved with a few lines of CSS. The html-apps-as-a-local-app (like electron-based stuff) became popular prior to "how to centre a div" was answered. IOW, they became popular in spite of having shitty layouts specifications.

Flexbox predates electron let alone electron being popular.

Re: Closing a 30 pixel gap between native and web

#242

Post by desindol »

pjmlp wrote: post #240
desindol wrote: post #234

Earlier quoted context omitted.

????? Nobody is saying that there aren’t webviews in office I am saying that your statement that most of the desktop office ui is now non native is false and misleading. After reading your other comments in the thread it seems like more of a personal vendetta than factual statements. lmao

Nope, you're the one interpreting that way, I only mentioned that they are adopting Web stuff as means to reduce code duplication between Web and desktop, via Webviews exactly. So unless you're on the Office team and want to tell us anything, please do lmao.

No post body was provided.

Re: Closing a 30 pixel gap between native and web

#243

Post by fuzzy2 »

mdmglr wrote: post #176
n8cpdx wrote: post #90

Earlier quoted context omitted.

> Traditional Windows apps all use system provided common controls, because they are good, and therefore they have a consistent look and feel, even through OS updates. This hasn’t been consistent since at least Vista and the release of WPF, which does totally custom control rendering. Circa 2006. 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 th…

> Even Office and Visual Studio (not Code) are using web technologies to render substantial parts of the UI. Any more details on what web technologies are being used in Visual Studio and what parts of the UI are done with web?

The Diagnostic Tools window is implemented as a web view, probably since its introduction in… VS2017?. I’m not aware of any other GUI parts implemented using web technologies.

Node.js processes are invisible backend stuff.

Re: Closing a 30 pixel gap between native and web

#244

Post by pjmlp »

desindol wrote: post #242
pjmlp wrote: post #240

Earlier quoted context omitted.

Nope, you're the one interpreting that way, I only mentioned that they are adopting Web stuff as means to reduce code duplication between Web and desktop, via Webviews exactly. So unless you're on the Office team and want to tell us anything, please do lmao.

Quoted post unavailable.

My dear I am quite free, unfortunely many people on this planet cannot enjoy the same freedom.

Re: Closing a 30 pixel gap between native and web

#245

Post by Rygian »

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…

On the flip side, I have become so used to AltDrag behavior on windows, that now I consider KDE alt-drag subpar because it lacks the right-button drag to resize.

Re: Closing a 30 pixel gap between native and web

#247

Post by dmitriid »

akmittal wrote: post #194
kajaktum wrote: post #167

Earlier quoted context omitted.

VSCode is adequate, not great. The bar for responsive and minimal application is so bad these days thanks to web apps.

VSCode replace Sublime, Visual Studio(full) and IntelliJ IDEs for so many developers. It has all the features >90% of developers and it is faster than VS and IntelliJ IDEs

It offers about 5 to 10 percent of all functionality of an IDE like IDEA. Much like devs on emacs and vim, most devs on VS Code have literally no idea what an IDE offers [1].

The things that worked in VS Code's favor:

- free. "All software must be free as in beer" is still a prevailing thought in IT, and people are loathe to pay for anything, even if that anything is extremely useful and very difficult to realise and support. On top of that IDEA still has a reputation of being expensive

- reasonably fast

- plugin system is decent and much easier to get into than IDEA, to keep IDEA as an example

- LSP is an overmarketed hype, but it worked in VSCode's immense favor. While it only covers a tiny sliver of things needed for a fully featured IDE, it covers enough of the important features, and is easy enough to implement. This way even languages that never had anything decent beyond broken syntax highlights in emacs and vim now enjoy at the very least an autocomplete

[1] Code refactoring alone is dozens of pages in IDEA docs https://www.jetbrains.com/help/idea/refactoring-source-code....

Re: Closing a 30 pixel gap between native and web

#248

Post by Bigpet »

tiarafawn wrote: post #10

Seems exploitable for phishing

you need to "install" the PWA first. So how's this different from regular desktop applications in regards to phishing specifically? Do you mean an app presenting pre-"install" as something and then post-"install" as something else?

I'm having a hard time seeing a lot of difference. Most windows you want to "spoof" will look different in regards to the title bar either way. In a regular browser window you'll have the browser title bar. In the PWA case you'll have the extra hamburger menu.

Re: Closing a 30 pixel gap between native and web

#249

Post by jsymolon »

p1necone wrote: post #126
dejawu wrote: 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.

> window snapping/tiling

Put me in the camp that hates window snap/tiling.

I have a certain workflow that needs this window there, and this one here ... don't snap to a location or go full screen.

Re: Closing a 30 pixel gap between native and web

#250

Post by catfishx »

armchairhacker wrote: post #26

I want the opposite of a PWA. I want an app which can be compiled into Desktop/mobile builds and also interpreted in browsers. An alternate HTML/CSS/JS with no JavaScript.

Rust egui: https://egui.rs/

Can be compiled for desktop, mobile and used in a browser with WASM

Post reply on HN