GTG

Groups for tags

Bug #321903 reported by Bertrand Rousseau
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GTG
Fix Released
Medium
Kevin Mehall

Bug Description

Tag list should provide a way to group related tags. To would be nice in order to be able to create a certain categorization of tags. Ex:

All tasks (17)
Tasks without tags (1)
----------
Contexts (8):
    @Home (3)
    @Work (4)
    @Downtown (1)
People (7)
    @Mike (6)
    @Ian (2)
@tag1 (0)
@tag2 (3)
@tag3 (1)

Tags: tags

Related branches

Changed in gtg:
importance: Undecided → Medium
status: New → Confirmed
Changed in gtg:
milestone: none → 0.2
Revision history for this message
Gabriel Bauman (gabrielbauman) wrote :

I've been doing this by 'namespacing' my tags.

 @context:home
 @people:mike

etc.

Changed in gtg:
milestone: 0.2 → 0.3
Revision history for this message
Lionel Dricot (ploum-deactivatedaccount) wrote :

kevin > any chance to see your branch ready for 0.2 or is it too early ?

Revision history for this message
Kevin Mehall (kevin-mehall) wrote : Re: [Bug 321903] Re: Groups for tags

It's working and I'm running it for normal use, but the TreeModel refresh
code is somewhat of a hack.
Before, GTG didn't do much to refresh the TagTreeModel when tags were added
as the tasks were loaded. It happened to work, but for some reason, using
child items in the TagTreeModel breaks things. There's a race condition in
which some tags don't show up.

I attempted (r310 of my branch) to refactor it and properly queue refresh
callbacks so it refreshes only the needed parts of the TagTreeModel, and as
few times as necessary. I couldn't get this to work properly, so I reverted
it and added a call to self.tags_tv.refresh() in TaskBrowser.on_task_added,
which makes it work, but there's a chance that would be slow if someone has
a lot of tasks or tags.

Can someone who knows more about the internals of GTG and GTK take a look at
this?

On Mon, Sep 28, 2009 at 2:30 AM, Lionel Dricot <email address hidden> wrote:

> kevin > any chance to see your branch ready for 0.2 or is it too early ?
>
> --
> Groups for tags
> https://bugs.launchpad.net/bugs/321903
> You received this bug notification because you are a direct subscriber
> of the bug.
>

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

Kevin > Things have changes *a lot* in this area. There's normally no need to refresh anymore.

Revision history for this message
Kevin Mehall (kevin-mehall) wrote :

I tried removing the self.tags_tv.refresh() call, and it's better than
before, but occasionally doesn't show the expander triangle and children of
some parent tags.

On Tue, Sep 29, 2009 at 1:20 AM, Lionel Dricot <email address hidden> wrote:

> Kevin > Things have changes *a lot* in this area. There's normally no
> need to refresh anymore.
>
> --
> Groups for tags
> https://bugs.launchpad.net/bugs/321903
> You received this bug notification because you are a direct subscriber
> of the bug.
>

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

Kevin > could it be something similar as bug #411420 but for the tag_treeview ? Have you any other problem ? If this is your only problem and we can solve it, do you think it worth merging your branch before 0.2 release ?

Changed in gtg:
assignee: nobody → Kevin Mehall (kevin-mehall)
Revision history for this message
Kevin Mehall (kevin-mehall) wrote :

It certainly seems like they could be related. Both are occasional odd behavior related to threads and refreshing. I hadn't noticed that bug before, but am able to reproduce it.

The only other problem I've seen is also likely related to this threading/TreeView issue: if you click to show children of a parent tag before GTG is done loading, it hangs with 100% CPU usage.

Assuming that gets fixed, it's up to you whether you want to merge before 0.2. When is 0.2 expected to be released? I'd definitely like it to get a little more testing before it goes out in a release.

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

Kevin > we fixed October 16th for the release because it's the birthday of the first commit. We can delay for a few days if needed but not too much. Sometimes, you just have to release.

Revision history for this message
Kevin Mehall (kevin-mehall) wrote :

The changes in trunk since this was last discussed make this code faster and way more stable. I haven't seen any of the problems I experienced before.

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

Merged with rev. 355. Please test !

Changed in gtg:
milestone: 0.3 → 0.2
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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