From: Benny M. <ben...@gm...> - 2009-07-17 10:42:53
|
Hi, about the event tab changes committed last night, http://blog.gramps-project.org/?p=135 There are probably still issues in the following use case: 1/open a person and select an event to share, see the the eventref editor pop up 2/in the eventview move to an event 3/update the event, and save. The callback will update the event view but also the event tab with the new code. This fits in light of the old and well known bug http://www.gramps-project.org/bugs/view.php?id=1277 I'll work on it on holiday, but am thinking that to solve all possible issues that can arise like that, we might perhaps better create a more fine grained callback system. That is, connect to eg the database signal update-event, but only if the eventhandle passed is in the changed list. That would move away parsing if one of the handles one works with are changed away from the callback function, into the caller of the callback. It would simplify things like the following: Open up the person editor, connect all primary events involved to a change of them specifically (so the families, the sources, the events, notes, ....). Then the person editor only recieves a callback signal if something that is really shown or stored in the editor changes. Something to think about. Benny |
From: Richard T. <rjt...@th...> - 2009-07-17 14:32:08
|
Hi Benny, inline... Benny Malengier wrote: > Hi, > > I'll work on it on holiday, but am thinking that to solve all possible > issues that can arise like that, we might perhaps better create a more > fine grained callback system. > That is, connect to eg the database signal update-event, but only if > the eventhandle passed is in the changed list. That would move away > parsing if one of the handles one works with are changed away from the > callback function, into the caller of the callback. > It would simplify things like the following: > Open up the person editor, connect all primary events involved to a > change of them specifically (so the families, the sources, the events, > notes, ....). Then the person editor only recieves a callback signal > if something that is really shown or stored in the editor changes. > Something to think about. The *update, *-add and *-delete events that the db generate already contain a list of the handles that have been affected. The code has changed *a lot* since I last contributed anything, but looking through now, at least in the EditPerson case, these handles are ignored: self._add_db_signal('family-rebuild', self.family_change) self._add_db_signal('family-delete', self.family_change) self._add_db_signal('family-update', self.family_change) self._add_db_signal('family-add', self.family_change) self._add_db_signal('event-update', self.event_updated) self._add_db_signal('event-rebuild', self.event_updated) self._add_db_signal('event-delete', self.event_updated) def family_change(self, handle_list=[]): """ Callback for family change signals. This should rebuild the backreferences to family in person when: 1)a family the person is parent of changes. Person could have been removed 2)a family the person is child in changes. Child could have been removed 3)a family is changed. The person could be added as child or parent """ #As this would be an extensive check, we choose the easy path and # rebuild family backreferences on all family changes self._update_families() Changing the callback code in the way that you suggest would be rather difficult. The callback code knows nothing of the things that are attached to the signals (by design), it just calls each method that has been connected. It does not even know anything of the meaning of the signals. Changing this would (in my view) be a mistake. You could filter the signals using a filter attached to the signal e.g (untested): self.db.connect( 'event-update', lambda handles: self.real_callback(set(my_handles).intersection(handles))] (forgive the bad formating of my email client). This would give you the same affect, i.e. the callback method would only be called when the handles of interest were updated. Regards Richard |
From: Benny M. <ben...@gm...> - 2009-07-21 12:25:56
|
Thanks for this suggestions and explenation Richard. I'll look into it. I can create with all editors broken databases now by changing things outside the editors and then clicking save in the editor. An arbitrary test though, and not likely to bite many users. I don't know this code, but to fix this, every editor will have to add quite a lot of callbacks to the database when opened (well, at least every editor to all source callbacks, most gallery callbacks, ....). Do you know if the code can cope with that, that is, is the design robust to having to do a lot of callbacks on any update? Benny 2009/7/17 Richard Taylor <rjt...@th...>: > Hi Benny, > > inline... > > > Benny Malengier wrote: >> Hi, >> >> I'll work on it on holiday, but am thinking that to solve all possible >> issues that can arise like that, we might perhaps better create a more >> fine grained callback system. >> That is, connect to eg the database signal update-event, but only if >> the eventhandle passed is in the changed list. That would move away >> parsing if one of the handles one works with are changed away from the >> callback function, into the caller of the callback. >> It would simplify things like the following: >> Open up the person editor, connect all primary events involved to a >> change of them specifically (so the families, the sources, the events, >> notes, ....). Then the person editor only recieves a callback signal >> if something that is really shown or stored in the editor changes. >> Something to think about. > > The *update, *-add and *-delete events that the db generate already > contain a list of the handles that have been affected. The code has > changed *a lot* since I last contributed anything, but looking through > now, at least in the EditPerson case, these handles are ignored: > > self._add_db_signal('family-rebuild', self.family_change) > self._add_db_signal('family-delete', self.family_change) > self._add_db_signal('family-update', self.family_change) > self._add_db_signal('family-add', self.family_change) > self._add_db_signal('event-update', self.event_updated) > self._add_db_signal('event-rebuild', self.event_updated) > self._add_db_signal('event-delete', self.event_updated) > > def family_change(self, handle_list=[]): > """ > Callback for family change signals. > > This should rebuild the > backreferences to family in person when: > 1)a family the person is parent of changes. Person could have > been removed > 2)a family the person is child in changes. Child could have > been > removed > 3)a family is changed. The person could be added as child or > parent > > """ > #As this would be an extensive check, we choose the easy path and > # rebuild family backreferences on all family changes > self._update_families() > > Changing the callback code in the way that you suggest would be rather > difficult. The callback code knows nothing of the things that are > attached to the signals (by design), it just calls each method that has > been connected. It does not even know anything of the meaning of the > signals. Changing this would (in my view) be a mistake. > > You could filter the signals using a filter attached to the signal e.g > (untested): > > self.db.connect( > 'event-update', > lambda handles: > self.real_callback(set(my_handles).intersection(handles))] > > (forgive the bad formating of my email client). > > This would give you the same affect, i.e. the callback method would only > be called when the handles of interest were updated. > > Regards > > Richard > > > |
From: Duncan L. <dun...@gm...> - 2009-07-31 20:44:47
|
2009/7/21 Benny Malengier <ben...@gm...>: > Thanks for this suggestions and explenation Richard. > I'll look into it. I can create with all editors broken databases now > by changing things outside the editors and then clicking save in the > editor. An arbitrary test though, and not likely to bite many users. It bites me every now and then. I rely on GRAMPS to remember the order in which I opened windows which every now and then means I do things to annoy GRAMPS when closing windows... and yes I lose freshly entered data with this. |