gtg team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

Forwarding my answer to the list since I (again) forgot to include it
in the recipients initially.

---------- Forwarded message ----------
From: Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>
Date: Tue, Jan 26, 2010 at 5:16 PM
Subject: Re: [Gtg] Migrating Task to TreeNode
To: Lionel Dricot <ploum@xxxxxxxxx>


On Tue, Jan 26, 2010 at 4:45 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>
> Hello,
>
> In the process of my refactorization, I will have to mak Task() a
> TreeNode.
>
> But I have some questions about Tree() and TreeNode() because that class
> definitely needs some comments and some love.
>
>
>
> 1) Why are there multiple nodes with the same ID????? Why, when I do a
> get_nodes(id), do I receive a list ? This seems very very very strange for
> me.

Please read my answer for #2 below before readig this.

GtkTreeViews (whose support was the initial target of the Tree
structure) don't support nodes with multiple parents, so it is
required to create a tree where nodes have only one parent, and
creating a node for each parent of an object. This technique enables
to uniquify each object-parent relationship, creating then multiple
nodes for one actual object. The get_nodes function gives all the
uniquified nodes corresponding to a single object. This issue is hard
to perceive for tags since they can have only one parent, but is
relevant for multiple-parents objects like Tasks.

>
> 2) Why, when removing a node, should I provide both the ID and the node
> itself ? What is the meaning of that ? Removing should take the ID only.

First implementations of the tree were considered in order to provide
a tree structure that would be object-agnostic. In other words, it
would not be required for the object attached to a tree node to
possess an id, that would be the business of the app that need access
to certain objects in a structured way (here, a tree). That's why the
Treenode is the object managing the ids. This code is also the
consequence of the organic evolution of the GTG codebase towards the
definition of GenericTreeModels for GtkTreeView, which were not
mastered at the time of their development. Retrospectively, the
refactoring you're considering now (which is the way to go, btw) can
potentially make this previous approach obsolete and unappropriate.

> 3) What is the self.ids of a TreeNode? I don't get it. It seems to contain
> the IDs of children then why isn't self.children a dic ?

Same answer.

> 4) Why does add_child need both id and child_object. It should be the
> object alone. (I guess the answer will be the same as for question 2)
>

Idem.

>
> Once I have answer to those questions, I will refactor a bit the Tree
> class then make Task a TreeNode so the Trees are directly built in the
> datastore and finally refactor the requester to take that into account (and
> also to make it easier after reading Bryce's comments on it)
>
>
> Lionel
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg
> Post to     : gtg@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg
> More help   : https://help.launchpad.net/ListHelp
>



--
Bertrand Rousseau



-- 
Bertrand Rousseau