gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Hello Luca and all,

I'm with Bertrand ATM, discussing how to get GTG out of my shit.

I believe I understand well your suggestion but it has 2 main problems:

1) It makes the workview feature useless. By essence, this feature needs
to only display tasks without parents.

2) Filters are used now in different places : tag counting, gtg-cli, …


With Bertrand, we came to the following proposition for you guys:

Given that:
A) it looks that liblarch is, itself, a good thing
B) our bug are coming from liblarch-gtk (because gtk is stateful when it
comes to its TreeModel)

->

We propose to abandon the idea of a direct TreeModel/Liblarch
interaction. Instead, liblarch-gtk will maintain a gtk.TreeStore that
will be in sync with Liblarch.ViewTree.

This is not optimal because we have to construct that TreeStore and
maintain it across all modifications of the liblarch.ViewTree. 
But it will solve all gtk.TreeView crashes and makes our job less
"I-debug-GTK-and-I-like-it-yes-spank-me-again".

This should not be really hard as only liblarch-gtk is involved
(FilteredTree will also need some cleaning).

What do you think,

Lionel


Le dimanche 28 novembre 2010 à 06:06 -0800, invernizzi.l@xxxxxxxxx a
écrit :
> Hello people,
> == tecnical part, skippable ==
> I am looking at ways to have a nice tree structure like the one
> liblarch is aiming at without having to write a GenericTreeModel
> (because gtk is under-documented and buggy, as Lionel knows very
> well).
> Now, basically we started to look at the GenericTreeModel because the
> gtk TreeModelFilter does not offer the kind of filtering gtg is
> currently adopting: in gtk, if a node of the tree is marked as
> invisible, all its child are not displayed, while in gtg we really use
> a collapsed view of the tree in which only visible nodes are shown.
> == non tecnical part, I need your opinion on this ==
> We can avoid all these problem if we decide to play along with gtk
> rules. Instead of using the filters to showing *only* the tasks which
> match the filter, why don't we show those tasks and their parents,
> using the ui to highlight the matching tasks?
> This behaviour is coded in the attached example. Play with it to
> better understand what I'm proposing.
> 
> The main benefit of this solution, except that is super-easy to code,
> is that it shows in a non-obtrusive way also the parents of the tasks
> which match the filter (a feature that has been asked for several
> times).
> 
> What do you think?
>  Luca
> 
> 
> 
> ps: I think I found out why deleted tasks are still maintained in
> memory. It's, by design, a property of gtk tree models.
> 
> >From http://www.pygtk.org/pygtk2tutorial/sec-GenericTreeModel.html:
> """One of the problems with the GenericTreeModel is that TreeIters
> hold a reference to a Python object returned from your custom tree
> model. Since the TreeIter may be created and initialized in C code and
> live on the stack, it's not possible to know when the TreeIter has
> been destroyed and the Python object reference is no longer being
> used. Therefore, the Python object referenced in a TreeIter has by
> default its reference count incremented but it is not decremented when
> the TreeIter is destroyed. This ensures that the Python object will
> not be destroyed while being used by a TreeIter and possibly cause a
> segfault. Unfortunately the extra reference counts lead to the
> situation that, at best, the Python object will have an excessive
> reference count and, at worst, it will never be freed even when it is
> not being used. The latter case leads to memory leaks and the former
> to reference leaks.
> 
> To provide for the situation where the custom TreeModel holds a
> reference to the Python object until it is no longer available (i.e.
> the TreeIter is invalid because the model has changed) and there is no
> need to leak references, the GenericTreeModel has the
> "leak-references" property. By default "leak-references" is TRUE to
> indicate that the GenericTreeModel will leak references. If
> "leak-references" is set to FALSE, the reference count of the Python
> object will not be incremented when referenced in a TreeIter. This
> means that your custom TreeModel must keep a reference to all Python
> objects used in TreeIters until the model is destroyed. Unfortunately,
> even this cannot protect against buggy code that attempts to use a
> saved TreeIter on a different GenericTreeModel. To protect against
> that case your application would have to keep references to all Python
> objects referenced from a TreeIter for any GenericTreeModel instance.
> Of course, this ultimately has the same result as leaking references.
> """
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-contributors
> Post to     : gtg-contributors@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-contributors
> More help   : https://help.launchpad.net/ListHelp