GTG

[gtg-refactor] Tag pane does not show # of tasks

Bug #529256 reported by Bryce Harrington
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GTG
Fix Released
Critical
Luca Invernizzi

Bug Description

On gtg-refactor branch, the tag view is not showing the total counts, when launched using ./scripts/debug.sh - just shows 0.

Tags: regression

Related branches

Changed in gtg:
importance: Medium → Critical
Changed in gtg:
status: New → Triaged
Changed in gtg:
status: Triaged → Fix Committed
assignee: nobody → Luca Invernizzi (invernizzi)
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

I don't think that "active tasks" should be in the requester.

Active is just one of the many filters. In order to show the count in the tag pane, the tagtree should only get the current_view and get the number of tasks in that view.

The requester should not be modified.

Revision history for this message
Luca Invernizzi (invernizzi) wrote :

Ok then. I'll have a look in the next days.

Changed in gtg:
status: Fix Committed → In Progress
Revision history for this message
Luca Invernizzi (invernizzi) wrote :

Lionel, could you explain a little how filters can be used?
I have the filter "tasks with no tags" and the task tree. How do I apply the filter correctly?

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

in pseudo-code, what I think you need is the following :

1) ft = req.get_new_filtered_tree()
2) ft.apply_filter("notag_tasks")
3) ft.get_node_nbrs()

(that's the spirit)

Once it's working, we could optimize by caching the number and not parsing the whole ft every time but, before optimisation, we should have it work.

Revision history for this message
Luca Invernizzi (invernizzi) wrote :

Got that. Please review my commit, I think that it now follows the new GTG spirit.

BTW, now that I understand a little more these filters, I have to say that they're are quite an elegant coding idea!

I noticed that there is some delay on updating the values in the tags pane. Oh, well, time for another bug.

Changed in gtg:
status: In Progress → Fix Committed
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

Luca > Your commit seems perfect to me. Thanks for the good work :-) I should definitely take the time to document that.

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

One improvement that might help for the delay would be to keep a reference to the ft instead of building it all the time. It would be built only once when the tagtreeview is built and then you only have to use the "get_nodes_nbr" function.

Revision history for this message
Luca Invernizzi (invernizzi) wrote :

Did that, but the values are updated when you pass the mouse pointer over them.

Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

I think that, somewhere, the "row-modified" signal should be sent. Maybe you should check that with Bertrand.

Revision history for this message
Bertrand Rousseau (bertrand-rousseau) wrote : Re: [Bug 529256] Re: [gtg-refactor] Tag pane does not show # of tasks

On Fri, Mar 12, 2010 at 3:14 PM, Lionel Dricot <email address hidden> wrote:
> I think that, somewhere, the "row-modified" signal should be sent. Maybe
> you should check that with Bertrand.

Whenever a value has changed, if the object is already displayed on a
tree, it should be updated using a row-modified signal, yes. When you
pass over with the mouse, GTK calls get_value() to update the hovered
cell content.

>
> --
> [gtg-refactor] Tag pane does not show # of tasks
> https://bugs.launchpad.net/bugs/529256
> You received this bug notification because you are a member of Gtg
> contributors, which is subscribed to Getting Things GNOME!.
>

--
Bertrand Rousseau

Changed in gtg:
milestone: 0.3 → 0.2.9
Izidor Matušov (izidor)
Changed in gtg:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.