gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

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 :-(


Lionel

On Sun, 19 Sep 2010 14:23:49 +0200, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> This is my intended planning :
> 
> 1. In filteredtree.py, put a blocking lock for modifying and deleting
> functions. Only one of them could be run at the same time. Because of
> the __execution_loop, I'm not even sure that it is needed. Maybe
> replacing the boolean by a real lock is enough.
> 
> 
> 2. Modifying function should not modify directly self.cache_nodes and
> self.cache_vr but a copy of it. (self.tmp_nodes and self.tmp_vr).  The
> self.tmp_* should be copied into self.cache_* at the moment we are
> calling the callback.
> 
> 
> 3. That moment should be atomic, thus wrapped into a blocking lock.
> 
> 
> 4. All reading method should also acquire that same lock. The tricky
> part is for the recursive one.
> 
> 
> 5. Each time the self.tmp_ are copied into self.cache_, the
> self.state_id should be incremented.
> 
> 6. For each upstream call, liblarch_gtk should also get state_id and
> save it.
> 
> 7.  Each downstream signals from filtered tree should carry the new
> state_id. (for modified signals, it's not a new one, as the tree is not
> changed).
> 
> 
> 8. If liblarch_gtk receive a signal with a state_id <= than the
> currently saved state_id, the signal is dismissed.
> 
> 
> 
> 
> As you can see, only step 4 require some work.
> 
> 
> 
> _______________________________________________
> 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