Drag and dropping tasks open in the taskeditor on to tags should refresh the content of the editor

[Matthew Rasmus]

Steps to reproduce:

1)Create a new task from the quick add entry, then open the task (don't edit anything!)
2)While the task editor is open, drag and drop the task on to two (or more, if you wish)
3)Close the task and then reopen it
4)With the editor open, drag and drop it on to additional tags
5)Close and reopen...

Expected Results:

Task should list ALL of the tags that it was drag and dropped on to.

My Results:

Task only lists the tags from step 2, but still shows up under the tags in step 4.

It seems that if the task has undergone ANY editing (the inverse of the requirements needed to create bug #504409) it will not display any of the tags it receives via drag and drop if it is open in the editor while this happens.

[Luca Invernizzi (invernizzi)]

Would be better to add also the tag "@text" in the task editor as tags are added? I think that the current behaviour is not so straightforward (I'm writing it here and not opening a new bug because it may effect how this bug is solved).

[Matthew Rasmus (mrasmus)]

Luca Invernizzi wrote:
> Would be better to add also the tag "@text" in the task editor as tags
> are added? I think that the current behaviour is not so straightforward
> (I'm writing it here and not opening a new bug because it may effect how
> this bug is solved).
>

Yeah, updating the task editor as it happens is important, IMO,
otherwise it's really unclear what's going on to the user.

[Kevin Mehall (kevin-mehall)]

Luca> Yes, that's the desired behavior, but that text is already inserted. It's then overwritten due to a problem with the editor.

The reason this bug occurs is because the drag and drop modifies the task's content via Task.add_tag, and then the task editor saves over that content when the window is typed in or closed. We need to make the editor refresh the content from Task.content whenever it is changed, so that the added "@tag" text stays inserted. Currently, the editor assumes that it is the only thing that modifies the content.

The reason for the inconsistent behavior with empty text is because upon opening the editor, if the text is empty, "@tag" text will be inserted for each tag on the task. This is also the reason that only subtasks without text would be properly tagged in bug #504409. That fix does not affect this bug.

[Lionel Dricot (ploum-deactivatedaccount)]

"if the text is empty, "@tag" text will be inserted for each tag on the task."

This is clearly a regression as the tag should be inserted all the time if they are not already in the task. They are inserted between the title and the actual content, on the same line.

[Lionel Dricot (ploum-deactivatedaccount)]

(I propose bissection to find when that regression occurred )

[Kevin Mehall (kevin-mehall)]

I don't think it's a regression.

The add_tag function adds the text, but the task editor overwrites it. Then the next time the task editor is open, the code at editor.py:158 sees that the text is blank and adds the "@tag" text. That code is not typically triggered anymore, since add_tag should take care of it, and then the text is no longer blank. Though, IIRC, the quick add still uses the old tag_added and thus this code path.

[Kevin Mehall (kevin-mehall)]

Anyway, that's a separate issue. If the editor properly handled it when other parts of the code modified the text, I think this problem would be fixed. Then, we could try to make sure nothing uses that "add tags if blank" code and remove it. I think that goes along with bug #493368 in that the logic should be in the core, not handled by the UI layers.

[Lionel Dricot (ploum-deactivatedaccount)]

Well, since liblarch, we cannot anymore drag-n-drop a task to a tag. Could anyone hep me with this ? What should be done in theory ?

[Luca Invernizzi (invernizzi)]

mh.. I consider assigning tags via DnD one of the strengths of GTG. We should find a way to get that to work with liblarch.

[Lionel Dricot (ploum-deactivatedaccount)]

This is not really hard : it's just a matter of putting a "drag received" configurable function in liblarch_gtk. Then configure it to be "add_tag_to_task" in the treeview_factory.

[Lionel Dricot (ploum-deactivatedaccount)]

this is now implemented on the liblarch side. But the bug is still present and I know why :

the tags are saved if the task doesn't have a body. But if the task has a body content, when you close the editor, that body overwrite any other informations.

The proper way to do that would be to dynamically refresh the editor's content, which is a big task we need to do for 0.4.