relating to this, I don't immediately see how best to hack gramplets. They keep content if you move to an old database and refuse to upgrade. If you have an idea how best to fix. Connect to no_database I suppose,  although I see there is a
however, no update on the interface is done.
This is in gramps 34 also off course.


2012/8/30 Benny Malengier <>

I have had in trunk big issues with crashes on changing databases. It seems the callbacks for the listviews still come in while we already closed the database.

Revision 20296 fixes this for me in most cases, but changes how callbacks work. Please review and improve if my approach seems wrong. I don't really find the way we do things in branch 34 very logic.
For example, nobody emits no-database in branch 34 ...

So, the logic I converted to is:
1. first signal no-database, so views can connect to this, and empty their view, disconnect signals
2. create new db
3. load the file
4. if load ok, change the db in dbstate, which will trigger a database-changed signal (originally, the change was done in dbstate, then load, but in trunk this caused (I think, so many different issues at same time) updates in places before the load happens.
5. if load fails, no_database is called.

Then connecting to those views that trigger GTK3 callbacks the no-database signal of dbstate, allows to remove the callbacks before the database is gone (actually, I do set_model(None) now, but that gives the same.

This seems to work for me, but I remember signal order was changed in the past for some reason I don't remember, so perhaps there is a better way to fix the problems I had in trunk.