On Wed, May 19, 2010 at 01:43:05AM -0000, Luca Invernizzi wrote: > Signals are executed when "there is time for them", without specific > limits. > > Now, when we issue the signal task-deleted, we should do a series of things > (updating tags in the tag pane, removing the task and its children from the > main view...). > A number of times we need to access information about the task that has been > removed. Example: we need to check if the tag that we are updating in the > tags pane should be shown or not (are there still tasks tagged with that?) > > This causes a series of problems, among which the drag and drop "phantom > tasks" (tasks that are shown twice), or crashes upon deletion of tasks > because the signal arrived too late and we cannot get the list of tags > that need to be updated. > > How to solve this?instead of passing the tid along with the signal, I think > we should pass a copy of the whole task. > I understand there are a series of things that need to be well thought out > also with this approach and, since it's late and tomorrow is GTG Regression > day, i'll regress to bed.
Another thought would be to add a Trash Stack; when a delete action occurs, instead of outright deleting the task, it's moved to the Trash Stack and a set of flags assigned for the various jobs that have to be completed. Signal handlers can then reference the task by tid and get the data they need as they do their stuff. A reaper process periodically reviews the structure and frees objects who have all their job flags unchecked. The Trash Stack would not be persisted across program restarts, so care will need taken that no valid data references items in it. IOW, make sure to drop all references to the tid in data structures before putting it in the Trash. (This is a pretty crude garbage collection system, there may well be better pythonic garbage collection systems out there.) A fringe benefit of this is that an undo/undelete system could be hooked into it without too much hassle. -- sometimes task is removed before task-deleted signal handler is executed https://bugs.launchpad.net/bugs/582620 You received this bug notification because you are a member of Gtg contributors, which is subscribed to Getting Things GNOME!. Status in Getting Things GNOME!: Confirmed Bug description: Signals are executed when "there is time for them", without specific limits. Now, when we issue the signal task-deleted, we should do a series of things (updating tags in the tag pane, removing the task and its children from the main view...). A number of times we need to access information about the task that has been removed. Example: we need to check if the tag that we are updating in the tags pane should be shown or not (are there still tasks tagged with that?) This causes a series of problems, among which the drag and drop "phantom tasks" (tasks that are shown twice), or crashes upon deletion of tasks because the signal arrived too late and we cannot get the list of tags that need to be updated. How to solve this?instead of passing the tid along with the signal, I think we should pass a copy of the whole task. I understand there are a series of things that need to be well thought out also with this approach and, since it's late and tomorrow is GTG Regression day, i'll regress to bed. _______________________________________________ Mailing list: https://launchpad.net/~gtg Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg More help : https://help.launchpad.net/ListHelp
