gtg team mailing list archive

[Bertrand Rousseau <bertrand.rousseau@xxxxxxxxx>]

On Tue, Jan 26, 2010 at 5:41 PM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>
> 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.

That was actually the original aim of the Tree structure. I think we
have to find a smart way to relate the multiple-parent structure and
unique-parent structure to avoid re-duplicating the codes.

>
> Do you think it's possible ?

I hope so. I have no ready solutions here, but I have a good feeling about it.

> 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) ?

A TreeModel now uses a Tree object to parse the structure and retrieve
associated objects. So if we create two trees, one for active task,
the other for closed task, it's ok: it's just a matter of giving each
GtkTreeModel the correct tree. Since tasks will be pre-separated, we
will have to retrieve the filtering code in the browser. So all in all
it's a big plus since we will reduce filetring code (which, btw, is a
highly executed code: it is runned on each element everytime we
refresh the UI)

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

Yes, sure. It should give us a faster GTG, and consolidate our data
structures, which is more than needed since they are a bit messy
sometimes.

>
> 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
>>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg
> Post to     : gtg@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Bertrand Rousseau