gtg team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Very very very interesting reply !

So, if I summarize correctly :

1) what I want to achieve is good and I should do it that way.

2) but you were forced to do it the current way because of the multiple
parent problem.



Is this right ?

What I propose is to make Tree() support multiple parents but refactor
TaskTreeModel so it hides the multiple parents and make it like it is two
completely unrelated nodes. 

Do you think it's possible ?

If my refactorization gives you two Tree(), one for active tasks, the
other for closed tasks, do you think you will be able to change the
TaskTreeModel to use it (and handle the filters that way instead of via the
requester) ?

I realize that this is kind of a big refactorization but I also think it
definitely worth it.


Lionel


On Tue, 26 Jan 2010 17:16:20 +0100, Bertrand Rousseau
<bertrand.rousseau@xxxxxxxxx> wrote:
> 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
>>