strange behaviors with subtasks in taskeditor

Bug #496680 reported by fonji on 2009-12-14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Getting Things GNOME!
Lionel Dricot

Bug Description


I discovered a few strange behaviors while ... well, looking for them in the taskeditor.

If you create a new subtask, then put the cursor after the arrow and before the task's name, then press enter, the arrow will disappear but the subtask will still exist and its title will still be a link, at least until you write something.

If you create a subtask, then put the cursor before the arrow and enter any character, the subtask will be deleted, the text won't be a link anymore but the arrow will stay there, undeletable, until you remove any character on the right of it.
Then it becomes an arrow-character looking like that one: ⟶
And then you can delete it. If you copy this character, you'll get a '-' character (I think this comes from bug #339881).

Last thing, you can get weird behavior using copy-paste in the task editor.
If you create a subtask, then press enter, select the task's text and the following untitled one (with its arrow), copy and paste it directly, you can get something like this: (in this example my task's title was "asdfasfda") (original, isn't it?)
And then if you write something at the end of the line, only the new chars will appear as links.

Well, that's all for now.
I think there may be a few other things like that but I found no problem with normal usage (btw great work for the 0.2 version, liked the improvements) (specially the new calendars, with single clics and options 'today', 'later', ...).

Just for my future bug reports... for something like this, should I create three bugs? Seems to me that the problems are really close to each other, so I thought that grouping them may be useful. And should some of them be a comment on bug #339881?


Lionel Dricot (ploum) on 2009-12-15
Changed in gtg:
assignee: nobody → Lionel Dricot (ploum)
milestone: none → 0.3
Lionel Dricot (ploum) wrote :

Fonji > indeed, it's better to report 3 separate bugs with their specific usecase. At worst, a single commit will close multiple bug and it's not a problem ;-)

But don't comment on a closed bug. Reopen a new one instead except if you exactly experience a closed bug and you think it's a regression.

Changed in gtg:
milestone: 0.3 → 0.2.1
status: New → Confirmed
importance: Undecided → Medium
Lionel Dricot (ploum) wrote :

Your two first issues were fixed with commit rev. 495.

I don't understand the third issue so please fill a separate bug about it.

It's really great to have such detailed bug reports with an easy way to reproduce the bug. Please continue but also include what is the expected behavior (which I miss for your third point).

Changed in gtg:
status: Confirmed → Fix Committed
Changed in gtg:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers