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".
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
When this problem has been sorted out it should be possible to
close a Gramps database in the GUI. There is a feature request
On 30/08/12 22:29, Benny Malengier wrote:
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 <firstname.lastname@example.org>
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
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
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
Gramps-devel mailing list