3 ms·
Preservation of state from the user perspective, not from the application functional perspective. If I as a user quit an application, I'm not telling it to lose
by oneplane 8y ago
Preservation of state from the user perspective, not from the application functional perspective. If I as a user quit an application, I'm not telling it to lose my state, but if I close the state (i.e. one or more tabs/windows) that's what I want it to do. Closing/Quitting an application isn't analogus to killing a process. It is/was on some (but not all) other platforms, but not on macOS.
Quit and Close mean two different things. The state that is preserved is the state you put it in. So if the state is: I have a window open with a site loaded, then the next time I visit this task, I want that same state. If I tell a program that I wish to not see a window or site, then that is the state I put it in, and the next time I visit that same task/program, I want it to return to that state as well. While you might not agree with that logic, that is what the HIG describes and how it is implemented. The logic is there, and it is documented and followed, both on the desktop and on the ~1 billion mobile devices where much of the same HIG applies.
Let me add a car-analogy here:
Say you are in your car with the doors open and the engine running. If I turn off the engine, I don't expect my doors to close. And when I close my doors, I don't want my engine to turn off by itself. And when I open my doors, turn the engine off, go for a walk and come back, I expect my doors to remain open when I turn the engine back on.
Regarding the view state, Linux and Windows do this for the local machine, where as macOS does it for the directory. From a UX perspective both ways are with their own good and bad elements, but if you use multiple machines or manage multiple machines and share view states across machines and accounts, this is the way to do it (short of exchanging view state across other methods like a network or integrated into the filesystem).
Regarding your read-only mounting of mass storage and remote filesystems, that makes total sense to me, but makes zero sense for the general user. While it is nice to reconfigure your local system to do this (and macOS has this as well via autofs if you want it -- it's built in), this would make your environment completely unportable to anyone else.
- beagle3 8y ago> It is/was on some (but not all) other platforms, but not on macOS. I know why it's there. As I wrote in another post, this was a great choice in the 128KB/floppy days of the early macs. It no longer is - for the general user, on a computer (unlike a car) it feels like a distinction without a difference. The fact that it is consistent and based on consistent logic (albeit one that was prescribed 30 years ago) does not matter, IMO. > Regarding the view state, Linux and Windows do this for the local machine, where as macOS does it for the directory. I think you're rationalizing a poor design choice. For local files, the end result is mostly the same (except Linux preserves the directories mtime) -- as local files are rarely if ever accessed across the network by someone with write permissions for that directory. And those permissions often make it seam dysfunctional on a shared directory - you can't store settings, so it doesn't stay the same between visits. How does your explanation sit with the fact that there's a way to disable this for network/remote directories, but not for local ones? > and macOS has this as well via autofs if you want it -- it's built in I'm aware that's a power-user preference, I couldn't figure out how to do it on the mac; I'll look up autofs permissions - any recommended documentation?