Hacker News new | past | comments | ask | show | jobs | submit login

In my experience it is definitely a problem that comes up a lot introducing Windows 10 to people who have never used a computer before. They don't know what is running and what isn't, they don't know which window is focused if there are several on screen at once, they are afraid to poke around in the start menu in a way they weren't when it was simpler and clearer, and in general don't understand the meanings of icons and menus that used to be properly labeled. Windows 95 was a lot more clear and discoverable for someone who had never used a graphical computer.



> ... people who have never used a computer before. They don't know which window is focused if there are several on screen at once

This isn't just a problem for beginners: I'm old hat and I sometimes can't tell what Windows 10 has given focus to at times when I have several things on the go, especially over two or more screens where windows overlapping isn't the obvious go-to clue. The distinction between focused and not is sometimes so close to non-existent it might as well be completely non-existent (like the titlebar text+icons being a slightly different shade of grey), and it varies from app to app (even amongst Microsoft's output) so there is not one set visual cue to follow.

It definitely used to be better than this, including in Windows land.

When I get around to it (so probably never!) I intend to write a little tool that scans for the top-most window and draws a bright border around/over it somehow. I know this is possible (and probably not difficult) as I did some similar hacky window decorating back in the Win2K days[‡], but I've been almost entirely a database+infrastructure fellow for more than a decade and my desktop dev knowledge has rotted terribly.

[†] an always-on-top window positioned so it is a line across the top of the focused window would do, four such objects, one for each side, would be the easy hacky way to achieve a border, a single drawing surface with transparency and mouse click-through would be cleaner but with my current skillset more faf working out the relevant API jiggery-pokery or finding a library that wraps that nicely already

[‡] Using Delphi. Anyone else remember that? Does it still exist in a similar form?


In Settings > Colors you can choose an accent color and turn on the "Title bars and windows borders" option - I think that would give you exactly what you want.


Not everything does anything useful with that setting or even respects it at all, not even everything from MS, not even everything common from MS.

It does cover a fair few things, but not enough to calm my irritation!


I have found this option to be surprisingly inconsistent, both with built-in windows apps and with third-party apps. Many UWP apps don’t honor this at all, in addition to many electron apps.


Delphi is still around. A former coworker at my previous job (left this Jan) used it from time to time to make some quick little utilities. Not sure how well it's aged as I've never used it myself.


Delphi is still around in spirit through an IDE named Lazarus.

https://www.lazarus-ide.org/


> people who have never used a computer before

To be fair, back in 1995 the number of people who had never used a computer before was huge, so it made sense for companies like Microsoft to cater to their needs.

Today though, the fraction of people who truly have no computer experience must be utterly minuscule, so I can see that MS does not see the beginner experience as a priority any more.


Counterpoint: There was a headline recently in Japan about the fact that (IIRC) 40% of "kids" between 10 and 20 who do have a computer at home never used a computer. All they know is smartphones, Instagram, and Tiktok. Maybe Twitter. Some may be old enough to have used Facebook.


> They don't know what is running and what isn't

And they shouldn't. That's the idea Windows 10 tries to convey. Windows Store apps already stay in the background even after you close them. You shouldn't care which app is running or not. Clicking its icon would bring it up and that's the only thing the user needs to know.

iOS and Android already work that way.


> You shouldn't care which app is running or not.

I know that there is a strong culture that believes this, but this sort of thing drives me nuts. There are very good reasons why you you would both want to actually close programs and know what programs are running and what are not.

> Windows Store apps already stay in the background even after you close them.

This is one of the many reasons why I don't use Windows Store apps.


> There are very good reasons why you you would both want to actually close programs

Other way around: modern OSes don't want to make it look like programs aren't running when they really are (which has been possible ever since installable background services were created); modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.


And it's insanely idiotic. In the mobile world we have this due to a vastly different UX, and traditionally very limited resources. Remember the first iPhone didn't allow more than one app running. Today phones have fast CPUs and plenty of RAM, it's mostly about not draining the battery. None of these constraints apply to the desktop. Even on laptops power consumption is much less of a concern, unless you have some program going berserk spinning on 100% CPU.

So trying to bring this same concept to the desktop is insanely idiotic. Microsoft failed miserably by making Windows 8 a phone OS and then bringing it to the desktop with minimal changes. Windows 10 improved so much by actually focusing on the desktop again. Including such no-brainers as allowing store apps to run windowed. I'm not a Windows user anymore myself, but none of my friends who still have it as their daily driver like or use apps.


> modern OSes want to be able to close programs behind your back, while they seem to still be running, and then restore them to their previous state when you come back to them.

I thought they were suspending them, not closing them. Those are very, very different things.

In any case, pretending that applications aren't closed when they are is no better.


What is “suspending”? Like what https://github.com/maaziz/cryopid does? No OS uses such a technique for production process management. (Well, I guess you could say that Genode does if you consider VMs to be processes.) Processes are too non-self-sufficient for this to work with full generality. (For example, what would a process do if it “freezes” in the middle of executing within a shared library’s code section, and then an OS update is applied, replacing that library on disk? The “defrost” process would presumably re-run the dynamic loader, putting the new version of the library into memory; but now the defrosted thread’s PC points into the middle of an instruction. Oops!) CrypPID-like techniques only work in controlled environments, like if you’ve got a machine serving solely as a Docker container host and you want to “pause” containers.

On the other hand, if by “suspending” you mean “the OS asks the program to persist its running state to disk, which it can easily do because it’s using GUI-control and scene-graph frameworks that know how to serialize out their current state”—and then, when it has done this, the OS considers the process “clean” (like a clean page of disk cache) and therefore discardable—then yes, the OS is suspending processes.

Keep in mind that you need to add a flag to your application’s OS-readable metadata (the application manifest in Windows; the Info.plist in macOS/iOS) opting into this behaviour, signalling that your process is okay with being shut down at any time when it’s in the OS-visible “clean” state, and isn’t, say, a host for an RPC server that other applications are expecting to have a stable connection to.


>iOS and Android already work that way.

And honestly, it's annoying as hell sometimes. You never know when the system's going to kill an app or not. Sometimes you think something might stay in the background for a bit then it doesn't, other times you think you've killed something and it's still running, or it's started itself again. Manual memory management options keep getting stripped back in subsequent android versions. I get the idea behind why android works like this, but the lack of control bothers me.


The difference is that iOS and Android will kill apps as it sees fit. People come to expect that and know that reopening their reddit reader after a few hours, it might not be at the same state they left it.

On a desktop, this is different. You have to explicitly close programs. Because of this, it becomes important to know what's running and what isn't.


> The difference is that iOS and Android will kill apps as it sees fit.

Only because iOS and Android are wasting RAM (the former to a lesser extent, but iOS devices also have less RAM to begin with!) and running with zero swap space. (And the latter point in turn is due to the abysmal, bottom-of-the-barrel quality of phone eMMC storage.) This is not progress, it's just the OOM reaper being overactive for lack of a better option.


> and running with zero swap space. (And the latter point in turn is due to the abysmal, bottom-of-the-barrel quality of phone eMMC storage.) This is not progress, it's just the OOM reaper being overactive for lack of a better option.

And all this grief could be avoided by Linux actually allocating memory when its supposed to as opposed to just saying "Sure!" and then sometime later killing completely random programs when someone actually attempts to use memory they requested.


I wish I had more control over the mobile experience though. For example, my run-tracker apps will get closed and stop tracking me if I open too many apps during my run while leaving Spotify, Youtube, and my podcast apps open.

I'd like to be able to somehow pin the run-tracker as top priority. Sucks to realize after a run or bike ride that it stopped recording 20min into it.


Your run tracker should have a proper background service to make that not happen, or a persistent notification widget. If it is still happening, look around your power saving options to exempt it from being killed due to "excessive power usage" when in the background.


Windows Store apps follow the same semantics. When you close them, they are not unloaded from the memory and they restore their state at the startup even if you kill them. The "green leaves" next to the process name in Task Manager means that the app is suspended, but not killed, despite that it isn't open anymore.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: