From: Martin H. <Mar...@gm...> - 2005-05-18 07:46:19
|
Some more information. warning, long email ;-) This now seems to me related to signal handling in the InMemDB. When adding a media object to a grdb the following signals are emitted (I added some debug output): GrampsBSDDB: emmitting signal: media-add GrampsBSDDB: Calling callback with key: 25 MediaView.media_add( ['NNO5YM8C1YGP01O3S1']) GrampsBSDDB: emmitting signal: media-update GrampsBSDDB: Calling callback with key: 26 The signals meet the code in AddMedia, that is: self.db.add_object(mobj,trans) self.object = mobj self.db.commit_media_object(mobj,trans) When opening a GEDCOM file directly there is the media-add signal emitted twice, media-update is not emitted. The bug int the TreeView then occures after the second media-add (that adds the same handle): GrampsGEDDB: emmitting signal: media-add GrampsGEDDB: Calling callback with key: 25 MediaView.media_add( ['DRE2WMX9RNR5DJYJRW']) GrampsGEDDB: emmitting signal: media-add GrampsGEDDB: Calling callback with key: 25 MediaView.media_add( ['DRE2WMX9RNR5DJYJRW']) gramps.py:101: GtkWarning: file gtktreeview.c: line 4812 (validate_visible_area): assertion `has_next' failed. There is a disparity between the internal view of the GtkTreeView, and the GtkTreeModel. This generally means that the model has changed without letting the view know. Any display from now on is likely to be incorrect. gtk.main() (...) I then created a testcase: print "TESTING SIGNALS..." print "\nCREATE PERSON" p = RelLib.Person() self.db.add_person( p, self.trans) print "\nUPDATE PERSON" self.db.commit_person( p, self.trans) print "\nDELETE PERSON" self.db.remove_person( p.get_handle(), self.trans) print "\nCREATE FAMILY" f = RelLib.Family() self.db.add_family( f, self.trans) print "\nUPDATE FAMILY" self.db.commit_family( f, self.trans) print "\nDELETE FAMILY" self.db.remove_family( f.get_handle(), self.trans) print "\nCREATE EVENT" e = RelLib.Event() self.db.add_event( e, self.trans) print "\nUPDATE EVENT" self.db.commit_event( e, self.trans) print "\nDELETE EVENT" self.db.remove_event( e.get_handle(), self.trans) print "\nCREATE PLACE" p = RelLib.Place() self.db.add_place( p, self.trans) print "\nUPDATE PLACE" self.db.commit_place( p, self.trans) print "\nDELETE PLACE" self.db.remove_place( p.get_handle(), self.trans) print "\nCREATE SOURCE" s = RelLib.Source() self.db.add_source( s, self.trans) print "\nUPDATE SOURCE" self.db.commit_source( s, self.trans) print "\nDELETE SOURCE" self.db.remove_source( s.get_handle(), self.trans) print "\nCREATE MEDIA" m = RelLib.MediaObject() self.db.add_object( m, self.trans) print "\nUPDATE MEDIA" self.db.commit_media_object( m, self.trans) print "\nDELETE MEDIA" self.db.remove_object( m.get_handle(), self.trans) print "DONE." First I ran this on a grdb: TESTING SIGNALS... CREATE PERSON GrampsBSDDB: emmitting signal: person-add GrampsBSDDB: Calling callback with key: 5 GrampsBSDDB: Calling callback with key: 9 GrampsBSDDB: Calling callback with key: 13 UPDATE PERSON GrampsBSDDB: emmitting signal: person-update GrampsBSDDB: Calling callback with key: 6 GrampsBSDDB: Calling callback with key: 10 Gramps: emmitting signal: active-changed Gramps: Calling callback with key: 2 Gramps: Calling callback with key: 5 Gramps: emmitting signal: active-changed Gramps: Calling callback with key: 2 Gramps: Calling callback with key: 5 GrampsBSDDB: Calling callback with key: 14 DELETE PERSON GrampsBSDDB: emmitting signal: person-delete GrampsBSDDB: Calling callback with key: 7 GrampsBSDDB: Calling callback with key: 11 GrampsBSDDB: Calling callback with key: 15 CREATE FAMILY GrampsBSDDB: emmitting signal: family-add GrampsBSDDB: Calling callback with key: 1 UPDATE FAMILY GrampsBSDDB: emmitting signal: family-update GrampsBSDDB: Calling callback with key: 2 DELETE FAMILY GrampsBSDDB: emmitting signal: family-delete GrampsBSDDB: Calling callback with key: 3 CREATE EVENT UPDATE EVENT DELETE EVENT CREATE PLACE GrampsBSDDB: emmitting signal: place-add GrampsBSDDB: Calling callback with key: 17 UPDATE PLACE GrampsBSDDB: emmitting signal: place-update GrampsBSDDB: Calling callback with key: 18 DELETE PLACE GrampsBSDDB: emmitting signal: place-delete GrampsBSDDB: Calling callback with key: 19 CREATE SOURCE GrampsBSDDB: emmitting signal: source-add GrampsBSDDB: Calling callback with key: 21 UPDATE SOURCE GrampsBSDDB: emmitting signal: source-update GrampsBSDDB: Calling callback with key: 22 DELETE SOURCE GrampsBSDDB: emmitting signal: source-delete GrampsBSDDB: Calling callback with key: 23 CREATE MEDIA GrampsBSDDB: emmitting signal: media-add GrampsBSDDB: Calling callback with key: 25 UPDATE MEDIA GrampsBSDDB: emmitting signal: media-update GrampsBSDDB: Calling callback with key: 26 DELETE MEDIA GrampsBSDDB: emmitting signal: media-delete GrampsBSDDB: Calling callback with key: 27 DONE. The signalls look OK to me. No signals for the Events is OK because we dont have a View for them. Now the same when working on a GEDCOM directly: TESTING SIGNALS... CREATE PERSON GrampsGEDDB: emmitting signal: person-add GrampsGEDDB: Calling callback with key: 5 GrampsGEDDB: Calling callback with key: 9 GrampsGEDDB: Calling callback with key: 13 UPDATE PERSON GrampsGEDDB: emmitting signal: person-add GrampsGEDDB: Calling callback with key: 5 GrampsGEDDB: Calling callback with key: 9 GrampsGEDDB: Calling callback with key: 13 DELETE PERSON GrampsGEDDB: emmitting signal: person-delete GrampsGEDDB: Calling callback with key: 7 GrampsGEDDB: Calling callback with key: 11 GrampsGEDDB: Calling callback with key: 15 CREATE FAMILY GrampsGEDDB: emmitting signal: family-add GrampsGEDDB: Calling callback with key: 1 UPDATE FAMILY GrampsGEDDB: emmitting signal: family-add GrampsGEDDB: Calling callback with key: 1 DELETE FAMILY Warning: GrampsGEDDB: Signal emitted with argument that is not a tuple. emit() takes two arguments, the signal name and a tuple that contains the arguments that are to be passed to the callbacks. If you are passing a signal argument it must be done as a single element tuple e.g. emit('my-signal',(1,)) signal was: family-delete from: file: /home/martin/devel/gramps2/src/GrampsInMemDB.py line: 188 func: remove_family CREATE EVENT UPDATE EVENT DELETE EVENT CREATE PLACE GrampsGEDDB: emmitting signal: place-add GrampsGEDDB: Calling callback with key: 17 UPDATE PLACE GrampsGEDDB: emmitting signal: place-add GrampsGEDDB: Calling callback with key: 17 DELETE PLACE GrampsGEDDB: emmitting signal: person-delete GrampsGEDDB: Calling callback with key: 7 GrampsGEDDB: Calling callback with key: 11 GrampsGEDDB: Calling callback with key: 15 CREATE SOURCE GrampsGEDDB: emmitting signal: source-add GrampsGEDDB: Calling callback with key: 21 UPDATE SOURCE GrampsGEDDB: emmitting signal: source-add GrampsGEDDB: Calling callback with key: 21 DELETE SOURCE GrampsGEDDB: emmitting signal: source-delete GrampsGEDDB: Calling callback with key: 23 CREATE MEDIA GrampsGEDDB: emmitting signal: media-add GrampsGEDDB: Calling callback with key: 25 UPDATE MEDIA GrampsGEDDB: emmitting signal: media-add GrampsGEDDB: Calling callback with key: 25 DELETE MEDIA DONE. It now looks to me that like a bug in the InMemDB that is somehow mixing functions or signals. Cheers, Martin. > --- Ursprüngliche Nachricht --- > Von: "Martin Hawlisch" <Mar...@gm...> > An: gra...@li... > Betreff: [Gramps-users] MediaView has bug in TreeModel > Datum: Tue, 17 May 2005 13:35:57 +0200 (MEST) > > Hi, > > I dont know how exactly to reproduce it, but it seems to happen for me > when > opening a gedcom file directly from the commandline, but only when the > gedcom does not contain media objects. > Then go to mediaView and add a new media object. (for testing I simply > press > OK, which creates the reference to a folder). > > You see the newly created media object listed in the view. when moving the > mouse up and down in the treeview sometimes a second entry appears and > errors are printed to the console: > > $ python gramps.py /tmp/CALD1813.GED > Trying to open: /tmp/CALD1813.GED ... > Type: GEDCOM file > Opened successfully! > gramps.py:101: GtkWarning: file gtktreeview.c: line 4812 > (validate_visible_area): assertion `has_next' failed. > There is a disparity between the internal view of the GtkTreeView, > and the GtkTreeModel. This generally means that the model has changed > without letting the view know. Any display from now on is likely to > be incorrect. > > gtk.main() > > ** (gramps:2558): CRITICAL **: pygtk_generic_tree_model_get_value: > assertion > `VALID_ITER(iter, tree_model)' failed > > (gramps:2558): GLib-GObject-CRITICAL **: g_object_set_property: assertion > `G_IS_VALUE (value)' failed > > (gramps:2558): GLib-GObject-CRITICAL **: g_value_unset: assertion > `G_IS_VALUE (value)' failed > > ** (gramps:2558): CRITICAL **: pygtk_generic_tree_model_get_value: > assertion > `VALID_ITER(iter, tree_model)' failed > > (gramps:2558): GLib-GObject-CRITICAL **: g_object_set_property: assertion > `G_IS_VALUE (value)' failed > (...) > > > Don: maybe you can have look for this when enabling sorting in the media > view ;-) > > Cheers, Martin. > > > > -- > Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! > Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click > _______________________________________________ > Gramps-users mailing list > Gra...@li... > https://lists.sourceforge.net/lists/listinfo/gramps-users > -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ |