except that almost every shortcut that involves one of those special keys has an alternate shortcut that doesn't require them. Don't get me wrong, I use those keys myself, but I also find that with only a few exceptions (that can be reconfigured in the registry to not be exceptions) there is no actual NEED for those keys.
It would certainly open whole new avenues of scientific research if it turned out that something like a cesium clock can suddenly have such a disparity from it's regular exponentially fractional precision. I would really like to read some of the doctoral papers that would suddenly arrise in an attempt to understand and explain the occurance.
Personally, I prefer having a save button because it's easier to code a "dump contents to location" function than it is to code a "keep an infinate number of named previous states stored at random intervals" automated function and a user controlled function "keep current state, revert to user selected previous state". Using such a revision history would also be insanely wasteful of RAM and would greatly reduce system performance with contstant or extended use.
Besides, what do you do when you exit the program? If we assume the program uses the auto-save model I just listed above than the program would have to do one of 4 things (other options exist, but would be less than totally reasonable):
[1] Save, overwritting the original file and clearing the revision history on close. (saves disk space, strong posibility of unwanted data loss due to overwrite, does not require any other save features)
[2] Save the entire revision history to some file that is somehow directly linked to the original file. (maintains original data and revision history, will become enormously wasteful of storage space; also raises the question of how the original file came to exist to begin with, would probably require that some other save feature be available)
[3] Prompt the user for action. Assume that options will include Overwrite, Save as new, Discard changes. (allows for discarding the change history, grants the user control of final actions, but requires user interaction to close, could act as the only save feature)
[4] Discard everything, original file remains as is. (insures original data safety, easy to implement, requires that some other save feature be available)
Based on this, it's probably best to have a save feature available in program regardless.
That would be because your Palm runs entirely within RAM. So long as the battery doesn't die or lose connection the RAM stays powered and you don't lose anything. But if something happens to that power the only way for you to keep anything is to move it to a memory stick.
This I know from experience. My Clie has a faulty battery connection (and yes, it's well out of warranty, so don't tell me to just return it for a replacement), I have to run it with an external power supply and every time I power it off it resets to the hard-coded factory defaults.
Slashdot Mirror
Ah, but you want to have sex? Scandelous!
</sarcasm>
except that almost every shortcut that involves one of those special keys has an alternate shortcut that doesn't require them. Don't get me wrong, I use those keys myself, but I also find that with only a few exceptions (that can be reconfigured in the registry to not be exceptions) there is no actual NEED for those keys.
It would certainly open whole new avenues of scientific research if it turned out that something like a cesium clock can suddenly have such a disparity from it's regular exponentially fractional precision. I would really like to read some of the doctoral papers that would suddenly arrise in an attempt to understand and explain the occurance.
Personally, I prefer having a save button because it's easier to code a "dump contents to location" function than it is to code a "keep an infinate number of named previous states stored at random intervals" automated function and a user controlled function "keep current state, revert to user selected previous state". Using such a revision history would also be insanely wasteful of RAM and would greatly reduce system performance with contstant or extended use.
Besides, what do you do when you exit the program? If we assume the program uses the auto-save model I just listed above than the program would have to do one of 4 things (other options exist, but would be less than totally reasonable):
[1] Save, overwritting the original file and clearing the revision history on close. (saves disk space, strong posibility of unwanted data loss due to overwrite, does not require any other save features)
[2] Save the entire revision history to some file that is somehow directly linked to the original file. (maintains original data and revision history, will become enormously wasteful of storage space; also raises the question of how the original file came to exist to begin with, would probably require that some other save feature be available)
[3] Prompt the user for action. Assume that options will include Overwrite, Save as new, Discard changes. (allows for discarding the change history, grants the user control of final actions, but requires user interaction to close, could act as the only save feature)
[4] Discard everything, original file remains as is. (insures original data safety, easy to implement, requires that some other save feature be available)
Based on this, it's probably best to have a save feature available in program regardless.
That would be because your Palm runs entirely within RAM. So long as the battery doesn't die or lose connection the RAM stays powered and you don't lose anything. But if something happens to that power the only way for you to keep anything is to move it to a memory stick. This I know from experience. My Clie has a faulty battery connection (and yes, it's well out of warranty, so don't tell me to just return it for a replacement), I have to run it with an external power supply and every time I power it off it resets to the hard-coded factory defaults.