Benny,

This has been a problem before I started using Gramps.

We started to propose a solution in "2092: Running 'Tools > Database Repair...' with no database open".

http://www.gramps-project.org/bugs/view.php?id=2092

I like the idea of re-enabling the 'no-database' signal.  Views and gramplets could connect to this.  Gramplets could have a default clear method which could clear the text buffer of text gramplets.  GUI gramplets should override this.

I don't know why we create a dummy database instance when no database is open.  If dbstate.open is False then setting dbstate.db to None should be valid.

At some point I remember views initialising twice - we should avoid this.

When this problem has been sorted out it should be possible to close a Gramps database in the GUI.  There is a feature request for this:

http://www.gramps-project.org/bugs/view.php?id=4442

Nick.


On 30/08/12 22:29, Benny Malengier wrote:
Doug,

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
                self.set_has_data(False)
however, no update on the interface is done.
This is in gramps 34 also off course.

Benny

2012/8/30 Benny Malengier <benny.malengier@gmail.com>
All,

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.

Benny



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/


_______________________________________________
Gramps-devel mailing list
Gramps-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gramps-devel