gtg-contributors team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

On Tue, Sep 21, 2010 at 1:49 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> I followed all those steps. It doesn't work.
>
> It seems that when using treemodel with:
>
> DEBUG_MODEL = True
> TM_USE_SIGNALS = False
> TM_IDLE_ADD = True
> THREAD_PROTECTION = True
> ROW_IDLE_ADD = False
>
>
>
> We have some oddities : some task are duplicated, some are not displayed.
> I thought that it was caused by the TreeView receiving signals while, at
> the same time, building the tree by exploring it.
>
>
> I was correct for the build part : when we call gtk.Treeview.show(), it
> starts exploring the tree and handle signals as well. That's why some tasks
> were duplicated at start. Implementing the steps described solved that
> particular problem.
>
> But, afterward, TreeView seems to only care about signal !  It means that
> we cannot dismiss any signals anymore.  That's weird : we would have to
> block signal until the Treeview built his first representation but there's
> no way to know when it is finished.
>
> I manually reenabled signals after the first build but it doesn't work
> better than previously.  It means that I will discard the approach
> described here for now.
>
> Ok, I'm lost. That's bad :-(

I'm starting to be convinced that the possibility of building a
working custom gtk.TreeModel is very remote, thanks to the beautiful
gtk documentation and behavior.
Since we're spending most of our "developing power" on this effort,
perhaps we should just drop liblarch-gtk connections to liblarch and
rebuild the tree there. I know that it defeats some of the purpose of
liblarch, but we'd still keep the tasks in a generic tree. Even if
somehow we get this right, thanks to the  state of gtk on this matter,
I'm quite sure it would be a maintainer nightmare.
Sorry, Lionel, lilarch was a cool idea.