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

141–150 of 313 posts

Re: Closing a 30 pixel gap between native and web

#141

Post by crtasm »

seandoe wrote: post #107
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.

Me too. Don't forget about right-click + key to resize the window. I have to use a mac for work and so use Easy Move+Resize to get this same functionality.

alt + right click to resize! how did I never discover this one, thanks

Re: Closing a 30 pixel gap between native and web

#142

Post by MereInterest »

bitwize wrote: post #137
MereInterest wrote: post #125

Earlier quoted context omitted.

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

I won't say I'm not annoyed at it. When I want to switch back to the Linux partition and Windows instead decides to spend half an hour installing updates, it becomes another reason not to switch to Windows the next time.

Re: Closing a 30 pixel gap between native and web

#143

Post by mappu »

jimmygrapes wrote: post #70
MartinMond wrote: post #30

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

A while back at $DAYJOB I tried to get a CI pipeline to bundle our docs as .chm, but the official tooling (hhc, with-or-without Sphinx as a frontend) is windows-only pre-unicode nonsense; the only Linux native chm compiler i found was Halibut (from the author of PuTTY) which has many of its own idiosyncrasies.

Is there any normal-looking way to make a chm from a directory full of html files?

Re: Closing a 30 pixel gap between native and web

#144

Post by RedShift1 »

n8cpdx wrote: post #90
GuB-42 wrote: post #86

> installed desktop web apps are really starting to look and feel like native apps I think we are having the opposite problem: native apps are really starting to look and feel like web apps, and in many cases, they are. The problem: the web has a terrible UI toolkit for desktop apps. It has clickable links and basic forms, that's all. It was made for documents, not apps. If you want better than that, you have to rewr…

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

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

What is a decent color picker? Everybody's idea about that is different so basically no 2 websites use the same color picker. In fact, this paper [1] found that the kind of picker (RGB vs HSV, etc...) doesn't really matter, but that better feedback made the difference. So will we get instant feedback from our color pickers now (for example text immediately turning into the color selected)? No, because designers design how they think it should look and feel, not based on how people actually interact with applications.

[1] https://www.researchgate.net/publication/220183526_Model_and...

Re: Closing a 30 pixel gap between native and web

#145

Post by userbinator »

marcosdumay wrote: post #78
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…

The Windows style for bars (both title and status) is way too large. Ditto for the task bar. It's no wonder people are tempted to not use status bars, and shove as much as possible at the title. If applications could exploit the task bar, they would too. (Anyway, you don't need an entire bar for system interaction. But applications aren't designed in a way that allows this.)

It's not, or at least it wasn't prior to ~Win8 or so. Yet monitor resolutions have steadily increased, so perhaps it's a reasonable on with a huge monitor.

Anyway, you don't need an entire bar for system interaction

Having to click on a tiny area to move a window, instead of a relatively wide rectangle, is a huge regression.

Re: Closing a 30 pixel gap between native and web

#146

Post by userbinator »

Analemma_ wrote: post #82
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…

Hard disagree. Vertical space is a scarce resource and I hate when it's used for dead space I can't get rid of or use productively. Alt-drag is the way to go.

That's ridiculous. 640x480 used to be the norm for Windows, and now monitors with 4.5x that vertical resolution are common.

Instead you should be complaining about the trend of apps spacing everything out with excessive amounts of padding.

Re: Closing a 30 pixel gap between native and web

#147

Post by n8cpdx »

RedShift1 wrote: post #144
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…

> 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). What is a decent color picker? Everybody's idea about that is different so basically no 2 websites use the same color picker. In fact, this paper [1] found that the kind of picker (RGB vs HSV, etc...) doesn't really matter, but that better feedba…

This one looks pretty solid. There are loads of them. The demos I’ve seen all showcase live feedback.

https://superguigui.github.io/simple-color-picker/

Compare to the best I can find for WPF: https://github.com/dsafa/wpf-color-picker - no live feedback, dialog only, no documented support for modern .NET. There are some commercial controls available from syncfusion and the like if you want to pay for such things.

Compare to color dialog in WinForms: https://github.com/Kinnara/ModernWpf/issues/72

WinUI has a decent color picker, but there are other trade offs going with WinUI that make it inferior to the web environment (e.g. broken rendering of SVG/paths).

Re: Closing a 30 pixel gap between native and web

#148

Post by Morgawr »

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…

>AltDrag

That's awesome, I remember when I was a CS student in college I also fell in love with the alt+drag of windows on Linux and I wanted to bring the same on my Windows PC so I wrote this extremely hacky and very unstable tool: https://github.com/Morgawr/EmptyWM

It was one of my first "open source" projects and a great learning experience, I would never recommend anyone to use it because it was full of bugs (also I haven't touched it in like 10+ years) but I used it every day and it was such a great feeling just being able to improve my own life with tools I created myself. :)

Re: Closing a 30 pixel gap between native and web

#149

Post by bitwize »

fragmede wrote: post #122
com2kid wrote: post #83

Earlier quoted context omitted.

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.

The most basic of window operations should have a visual affordance right in the UI because they're basic and no one should have to pause and ask themself "how do I move/resize a window?"

Remember your Bruce Tognazzini. Shortcuts are just that: shortcuts. They are NOT your primary interface. Everything should be visible and usable with just the mouse.

Re: Closing a 30 pixel gap between native and web

#150

Post by drekipus »

quotemstr wrote: post #129
drekipus wrote: post #69

Earlier quoted context omitted.

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.

super+h minimises. pretty sure you can make it anything you want.

if you're looking specifically for "alt-spc n" to minimise I'm sure you can find a way to make that work - but why? to retain muscle memory between windows and gnome?

Post reply on HN