Without disrespect of your view, I do disagree on both points. I suspect I'm not the only one who looks for autorecover to do as it implies it will.
On config saving, nothing you've written says why it's a bad idea or not worthwhile saving changed settings when the user clicks "ok" or exits that dialog. It's not exactly difficult - the code to do so exists, it's called on app exit anyway, the code to write its updated content can be put into a single function if not already done and called on dialog exit instead, with next to zero work. The most I see in what you write is "only badly written programs would do this" (why?), "It's a hangover from Win Registry" (is it? and what about that makes it bad anyway?), "The dialog doesn't say 'save' " (change it?) and "People don't do that" (harm of doing so is?). Is anyone out there going to go "Oh no, my settings got saved when I clicked OK, and I didn't expect them to be, I was just going to crash the session to stop them being saved"? Of course not. The expectation is they are saved, or if not, it's because they are changed again and then saved.
I also disagree with dismissing autorecover as a feature. It can be crucial. Not all scenarios afford the safety and stability you expect, not all users start from an assumption "nothing's certain so why care if a given precaution isn't working as it should", and accidents can happen. Multi-layered/first lines of defence are not inappropriate and catch many of the (hopefully few) data loss cases. Power can be unreliable, the cleaner trips over a wire, a colleague makes a mistake, wrong button clicked, OS or hardware crashes - who hasn't had these. Some users (through skill, knowhow or circumstance/fincance/hardware) can't or won't take every precaution you might. It's not unreasonable they trust IDM to have written autorecovery that works for when the issue is a "once-off" and the session can resume. "More fool you for trusting the author of the package" is not a good way to advertise support for customers.
While I accept you have the philosophy you do, I hope you can accept others may not share it - and that's valid too. Some of us explicitly verify our disk copies (even though HD copy *should* be reliable), checksum our backups, and make sure our working software's data loss prevention also does its job. When using networked devices, one usually chooses multi-layered security, however unlikely a hack attempt might be. When using an application that will cost time and difficulty if data is by accident lost, one uses multi-layer data loss protection. An autorecover function that doesn't autorecover robustly is like an airbag that doesn't reliably inflate, or a parachute that doesn't reliably open. Ideally you'll never need it. If you're cautious, you'll make sure it's reliable and will work in that (hopefully) rare event anyway.
It's not just personal opinion either. Someone at IDM spent time adding that autorecover function to UE. IDM decided it's worth that time investment. Presumably that person believed that UE sessions were improved or made more reliable with autorecover, or they wouldn't have done that.
I tend to side with them.
I accept if you disagree, but hope you understand my view on the importance.
On config saving, nothing you've written says why it's a bad idea or not worthwhile saving changed settings when the user clicks "ok" or exits that dialog. It's not exactly difficult - the code to do so exists, it's called on app exit anyway, the code to write its updated content can be put into a single function if not already done and called on dialog exit instead, with next to zero work. The most I see in what you write is "only badly written programs would do this" (why?), "It's a hangover from Win Registry" (is it? and what about that makes it bad anyway?), "The dialog doesn't say 'save' " (change it?) and "People don't do that" (harm of doing so is?). Is anyone out there going to go "Oh no, my settings got saved when I clicked OK, and I didn't expect them to be, I was just going to crash the session to stop them being saved"? Of course not. The expectation is they are saved, or if not, it's because they are changed again and then saved.
I also disagree with dismissing autorecover as a feature. It can be crucial. Not all scenarios afford the safety and stability you expect, not all users start from an assumption "nothing's certain so why care if a given precaution isn't working as it should", and accidents can happen. Multi-layered/first lines of defence are not inappropriate and catch many of the (hopefully few) data loss cases. Power can be unreliable, the cleaner trips over a wire, a colleague makes a mistake, wrong button clicked, OS or hardware crashes - who hasn't had these. Some users (through skill, knowhow or circumstance/fincance/hardware) can't or won't take every precaution you might. It's not unreasonable they trust IDM to have written autorecovery that works for when the issue is a "once-off" and the session can resume. "More fool you for trusting the author of the package" is not a good way to advertise support for customers.
While I accept you have the philosophy you do, I hope you can accept others may not share it - and that's valid too. Some of us explicitly verify our disk copies (even though HD copy *should* be reliable), checksum our backups, and make sure our working software's data loss prevention also does its job. When using networked devices, one usually chooses multi-layered security, however unlikely a hack attempt might be. When using an application that will cost time and difficulty if data is by accident lost, one uses multi-layer data loss protection. An autorecover function that doesn't autorecover robustly is like an airbag that doesn't reliably inflate, or a parachute that doesn't reliably open. Ideally you'll never need it. If you're cautious, you'll make sure it's reliable and will work in that (hopefully) rare event anyway.
It's not just personal opinion either. Someone at IDM spent time adding that autorecover function to UE. IDM decided it's worth that time investment. Presumably that person believed that UE sessions were improved or made more reliable with autorecover, or they wouldn't have done that.
I tend to side with them.
I accept if you disagree, but hope you understand my view on the importance.
