6 ms·

Personally I almost never agree with these "the desktop is dead" kind of articles. If anything, the problem this author has to be exacerbated by the move away

Personally I almost never agree with these "the desktop is dead" kind of articles. If anything, the problem this author has to be exacerbated by the move away from the traditional desktop style than an embrace of it. That preview close dialog is not something you'd see 20 years but is something you see in "apps" all the time. Perhaps the problem is, as you allude to, that software is hostile to the user now. There's always something more than simply being a tool that you buy, use, and close. Now most programs are merely portals for "services".

asymptosis 5y ago
This is spot on. People want to hand over responsibility for their computations to some big company offering a "free" service so long as you use the official app, and then they wonder why they don't feel like they have any power or freedom.
imglorp 5y ago
> Now most programs are merely portals for "services". More like three legs on that stool. The sale price, the services upsell, and then they leverate insights gained from capturing telemetry about you. Eg Windows is all three.
masklinn 5y ago
> That preview close dialog is not something you'd see 20 years That’s because the application would straight up lose the files without prompting. Also pretty sure text editors had something similar 50 years back, that’s why you :q! from vim, :q would tell you that you have unsaved buffers (or whatever the lingo is) and refuse. TFA is literally abusing a crash-resistance feature out of laziness, and will no doubt complain when it fails them. 20 years back we’d all trained ourselves to save with regularity to avoid issues, that feature would be considered manna from the heavens, and tfa absolutely mental. Completely stupidly too, I must add: > This is the dialog that I see every time I want to close the Preview app to clear my desktop of all that clutter in a hurry for a video call. MacOS has a shortcut to minimize all windows! It even has a shortcut to hide all aplications but the current one! You don’t need to close anything to “clear your desktop in a hurry”!
- deleted 5y ago
  [deleted]
- thu2111 5y ago
  Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. When Apple added multi-tasking to iOS later they copied the Android design more or less exactly. Browsers do something similar for browser tabs now. However this was never brought to the desktop, largely because native desktop APIs are dead and none of the companies that fund them are interested in improving them. We get the web and if it sucks, well too bad.
  - TeMPOraL 5y ago
    > Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference. > On mobile it doesn't happen, and we can thank Android for that To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting. I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).
    - horsawlarway 5y ago
      I agree with you about this distinction being important, but I come at it from a different angle - I don't mind if most apps operate in the background as they need, with preemptive scheduling like Android. But I really, Really mind if I don't have a rock solid way to quickly and easily kill an app (and all related tasks/processes/async jobs/etc). 1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location 2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'. I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".
deleted 5y ago
[deleted]

asymptosis 5y ago

This is spot on. People want to hand over responsibility for their computations to some big company offering a "free" service so long as you use the official app, and then they wonder why they don't feel like they have any power or freedom.

imglorp 5y ago

> Now most programs are merely portals for "services". More like three legs on that stool. The sale price, the services upsell, and then they leverate insights gained from capturing telemetry about you. Eg Windows is all three.

masklinn 5y ago

> That preview close dialog is not something you'd see 20 years That’s because the application would straight up lose the files without prompting. Also pretty sure text editors had something similar 50 years back, that’s why you :q! from vim, :q would tell you that you have unsaved buffers (or whatever the lingo is) and refuse. TFA is literally abusing a crash-resistance feature out of laziness, and will no doubt complain when it fails them. 20 years back we’d all trained ourselves to save with regularity to avoid issues, that feature would be considered manna from the heavens, and tfa absolutely mental. Completely stupidly too, I must add: > This is the dialog that I see every time I want to close the Preview app to clear my desktop of all that clutter in a hurry for a video call. MacOS has a shortcut to minimize all windows! It even has a shortcut to hide all aplications but the current one! You don’t need to close anything to “clear your desktop in a hurry”!

deleted 5y ago
[deleted]
thu2111 5y ago
Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. On mobile it doesn't happen, and we can thank Android for that, as they insisted from day one that multi-tasking APIs should not require the user to manually manage memory on the device. When Apple added multi-tasking to iOS later they copied the Android design more or less exactly. Browsers do something similar for browser tabs now. However this was never brought to the desktop, largely because native desktop APIs are dead and none of the companies that fund them are interested in improving them. We get the web and if it sucks, well too bad.
- TeMPOraL 5y ago
  > Yeah but the semantic difference between "hide" and "quit" is a very technical one that doesn't need to exist. Funny, because I think the exact opposite. "Hide" means, "stop showing it for now, but keep it around". "Quit" means, "I'm done with you and I expect you to not be doing any work until I start you again". It's a very significant usability difference. > On mobile it doesn't happen, and we can thank Android for that To this day I consider it to be the worst, most dumb idea Android ever had. I hate it. It's the reason I hated my first smartphone. It's the reason why, from the second phone on, I only ever buy top-of-the-line most overpriced flagships available - I have to overprovision resources to ensure the phone works smoothly, because there are countless of background processes doing god knows what, that cannot be killed and prevented from restarting. I know best when I'm done with an app. I want to be able to kill it, and all its background processes, and I want them to stay dead until I change my mind. If I were designing a mobile OS, I'd make the distinction between "hide" and "quit" as clear as day, and make it an app store policy violation for an app to execute anything in the background after being "quitted" by the user (polling for notifications would be handled by the system).
  - horsawlarway 5y ago
    I agree with you about this distinction being important, but I come at it from a different angle - I don't mind if most apps operate in the background as they need, with preemptive scheduling like Android. But I really, Really mind if I don't have a rock solid way to quickly and easily kill an app (and all related tasks/processes/async jobs/etc). 1. There are times I want to make sure an app is not running (think zoom/hangouts with video access), or a work app that records location 2. The single best way to fix a problem, any problem, is still 'turn it off and back on again'. I don't want to kill the current activity and hope that the background jobs stop at some point in the nearish future with absolutely no feedback or insight. I want "killall <root app process>" then give the app 5ish seconds to cleanup and if it's still around "killall -9 <root app process>".

deleted 5y ago

[deleted]