gtg team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

There was a little confusion in Task about deletion, because most of the times to delete a task "self.req.task_delete()" was called, which was not made for that (see previous comment).
The delete dialog itself called that function, but thanks to some misplaced signals everything worked almost perfectly:D

(in particular, the requester was signaling the deletion and then
telling the datastore to delete the task from the backend, which
triggered the removal from the tree and finally the removal from the ui.
Now it's Task->Tree->UI and Task->TaskSource(aka Backend))

Anyway, revision 800 in the linked branch is solves this.
Turns out that the only place where we needed to access a task after it was deleted was in the Tasktree, since we needed to know the paths to remove. I've added another signal to the filteredtree, "path-deleted", so that we don't have this bug anymore. We do need documentation, though, because I believe all this was caused by a misunderstanding on a function name.

If you didn't understand anything I said, I will repeat tomorrow. Not
it's 3:37, the *perfect* time to sleep :)

-- 
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!: In Progress

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.