On Oct 9, 2012, at 12:21 AM, Benny Malengier <benny.malengier@gmail.com> wrote:



2012/10/8 John Ralls <jralls@ceridwen.us>

On Oct 8, 2012, at 9:16 AM, Benny Malengier <benny.malengier@gmail.com> wrote:

>
>
> 2012/10/8 John Ralls <jralls@ceridwen.us>
>
> On Oct 8, 2012, at 8:02 AM, Benny Malengier <benny.malengier@gmail.com> wrote:
>
>>
>>
>> 2012/10/8 John Ralls <jralls@ceridwen.us>
>>
>> On Oct 8, 2012, at 6:48 AM, Benny Malengier <benny.malengier@gmail.com> wrote:
>>
>>>
>>>
>>> 2012/10/7 Paul Franklin <pf.98052@gmail.com>
>>> I think automatically disabling "Remember last view"
>>> whenever gramps is started with the database locked
>>> is a wonderful idea, and should go into 3.4.2 as I have
>>> seen dozens of users on the bug tracker asking what
>>> to do in this situation.  They are typically beginners
>>> (and as Jerome says typically after trying a buggy
>>> third-party addon) and we should prevent it happening.
>>>
>>> It is not related to the family tree though. It would be interesting to add to the config setting a clean-exit option. On opening of gramps it can be set to False, only the closing of gramps in a normal way should write True to it.
>>>
>>> Then on restart, if clean-exit is False, load the default Person View.
>>
>> Yes, that would be helpful.
>>
>> It would also be helpful to have a top-level exception handler that displays (or writes to a file in $HOME ) the traceback and cleans up and closes the database so that the user doesn't have to break the lock when s/he restarts. It won't help with segfaults, but almost all of the crash bugs I see are from unhandled exceptions .
>>
>> We have a top level exception handler.
>> With bugs, we don't always now the state of the database though, so you would have to close and restart behind the scenes I suppose to do what you would like.
>>
>> In my view, best is to fix the bugs, not to give the impression to the user all is fine while it is not.
>>
>
> Is Gramps not using Db Transactions to roll back to a known state before shutdown?
>
> Yes, but the user interface might be in another state, or unfinished due to a crash. After all, the crash is handled on a low level.
> I can only think of closing and reopening, which would clean up the user interface.

Ah, I wasn't clear. I didn't mean that the top-level handler should stop Gramps from shutting down, just that it should roll back and properly close the database first.

This is the case already. The lock is outside of the database, to avoid it being opened. If we store the lock in the database, a second instance needs to open it to check, and that could already give problems.
The lock is a text file in the database folder with True or False, and on crash, this file is just not cleaned up.

OK. Thanks for the explanation.

Regards,
John Ralls