It would be really, really helpful if DT remembered the window and tab state in the case of unexpected shutdowns (like a laptop battery draining) just as it does after a proper quit and as do most other programs with tabs. This is a common feature in nearly all programs with a similar interface such as web browsers. And it’s easy to program - simply record each change real time to a file. Besides, you already have the feature. All you have to do is change it to record to a file any time the state changes, not just during quit.
For the user, there is no way around this as we even lose the state of the previous proper shutdown even if it was 30 seconds ago. We are always forced to go back to the beginning.
As it is, the set up of tabs and windows makes a huge difference in my efficiency. Each time an unexpected shutdown has occurred it can take me hours to recreate the state of tabs that was last opened, if I can even do it at all.
To say the least this is very frustrating, especially considering that you already have the feature, but just haven’t properly implemented it.
This is actually intentional to prevent endless crash cycles. E.g. in the past certain documents (e.g. PDF or web archives) could crash the PDFKit or WebKit of Mac OS X and reloading the same tabs & documents on startup caused endless troubles.
Thanks for explaining this. I can see your point there; however, you can easily get around that in the same way that other products have done in the same situation. After a repeated crash have a dialog come up with a CHOICE of trying to open the same set again or going back to the previous saved state, or opening with virgin state.
Anyway, I don’t see that your present choice makes much sense as you could go back to the last saved state with a proper quit as that has shown itself to be stable. You have already implemented that feature, so why not use it after a crash, too. Additionally, you should be able to tell from your logs whether DT crashed or not. In my case, DT did not crash, the machine merely shut down because of a dead battery. It seems that if it did not crash that it could open safely again.
It appears that you have a number of alternatives in the way that you have programmed this and have chosen the most inconvenient for the user.
Regarding Workspaces. I wasn’t aware of them; however, while they are a partial solution, they still fall short in several ways. In particular, the state of my tabs is always changing and I would have to keep updating or creating a Workspace each time I opened or closed a tab or window. So, yes I could save a couple of generic Workspaces, it doesn’t come close to the dynamic memory of the window and tab state that you get when you simply quit DT.
It still doesn’t make sense why everything from the last stable state before a proper quit is lost with all other types of shut downs.
Anyway, thanks for the tip. Perhaps you could make workspaces more dynamic and especially more VISIBLE. I have used DT for years and constantly in recent months and would never have thought to look for such a feature at the bottom of the “GO” menu.
I love DTPO for the most part and constantly recommend it to my clients and friends (just recommended it to an Apple engineer today), but I occasionally come across some aspects of the design that really make me scratch my head and wonder what you were (not) thinking. Overall, this is a great program. It could really use some redesign in some aspects of the interface though.
I would never want the scenario suggested at the OP; not even as an option. Options get set inadvertently – just spend time reading some of the problems posted here. If DEVONthink allowed repeated crashes before it offered a CHOICE of not repeating that cycle, I would immediately wipe DEVONthink off every machine and never touch it again. I prefer Christian’s scenario: find and fix the root cause and don’t keep reloading the gun.
I agree with korm: A database crash is potentially dangerous to data, and I don’t want them to happen deliberately. (Always run Tools > Verify & Repair to check for errors, if there has been a crash.)
My databases remain stable, so a crash is a very rare event. Which is to say, I don’t have the OP’s problem of frequently having to reconstruct my set of open databases and windows.
Bottom line: If crashes happen, place the emphasis on eliminating the cause of a crash so as to achieve stability.
I never referred to an option such as a checkbox in preferences. ALL I was referring to is that after a crash, upon restart a dialog appears that says, “It appears that DevonThink has crashed. Do you want to attempt to reopen it with the last window configuration?”, along with the choice of yes or no. If it crashes repeatedly the dialog will not appear and DT can simply act the way it does now or, better yet, go back to a previous stable quit state.
This is already done by companies such as Apple itself, although I haven’t encountered it in a long time as I have had few crashes in their products. That said, another option comes to mind that is implemented in Safari - a menu choice to reopen all windows from the previous session. This will also restore all windows after a crash, but first Safari will open in a virgin state.
As for Christian’s idea and the root cause, we have always known the root cause and it has nothing to do with DT. It was a drained battery, plain and simple. Yesterday I also had a cat stand on the power button and shut the whole machine down. So DT is not having problems. It just loses it’s memory even when something unrelated causes it to quit.
I quess I should have put another title on the original post and said “Unexpected Shutdown”. I’m sorry that I said “crash”.
In this case and in other scenarios, there was NO problem with DT that caused it to quit. It was a drained battery in the most recent scenario. Should DT lose everything if it did not have a problem?
As you noted, Apple itself provides a procedure to restore after an application crash.
My experience is that it’s best not to accept that procedure, e.g., in Safari. Possibly Apple has corrected the glitches that happened to me when OK was accepted; I haven’t checked, and haven’t had an opportunity to check in a long time.
To put it another way, when the computer goes wonky, why should I assume there are no errors in memory or caches?
