Comment by PaulDavisThe1st
3 years ago
Sure, but is that actually "quitting" ? Depends on what the user actually expects "quit" to do.
Also, you're assuming that there is a thread that saves state to disk. There may be (and if the state save is a significant operation, there probably should be). But that's far from always the case.
The point here is that apps can be written to be both responsive and functional. They just aren’t, because devs don’t bother.
What you describe as "responsive" can be actually legitimately viewed as a trick.
If the GGP wants "Cmd-q" (for example) to cause a program to immediately stop using system resources, then all the "responsive" in the world will not satisfy that goal.
I agree that if GGP wants "Cmd-q" to cause a program to immediately vanish from the screen, the responsive design is the answer.
However, adding a thread to a program that takes 1 second to save it's state to disk in order to allow Cmd-q to cause the window to vanish immediately feels like overkill to me. You now need a bunch of thread mutual exclusion primitives that were (potentially) not necessary before. Not doing this is not "not bothering". It's facing the tradeoffs from adding a thread and deciding it is not worth it (a decision the user may not agree with).
If they want the first case, they can bind "xkill" to a keyboard shortcut. I actually have it on Win+C (like Ctrl+C in terminal).
I'm not into the proposed "saving threads", I'm afraid they will get stuck for whatever reason without you noticing (as the window/taskbar icon already disappeared).