gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Le mardi 21 septembre 2010 à 08:31 -0700, Luca Invernizzi a écrit :

> > 2. Use the gtk.gdk.Lock  (with gtk.gdk.lock)  (see the doc about it).
> >
> >
> > I recommand you to read :
> > http://friendpaste.com/2wKdvQpUKruG0PeUl2PKIV
> >
> >
> > What do you think ?
> 
> Sounds still very painful, but perharps it will work.
> Nice resource on this matter: http://live.gnome.org/GdkLock
> 
> Could you expand a bit on how the Treeview "explores" the TreeModel?
> I'm thinking that keeping a thin treemodel with only the rows stored.
> The model locks at every change, and it's unlocked by the ui. This is,
> basically, an easier version that the one you were thinking about
> (keeping a revision number of every change).

The "exploration" is highly dependant of what you have above your
treemodel (a treeview, a treemodelfilter or a treemodelsort). There
implementation is completely different.


I thought about an even easier idea, which is a gross hack but would
make it fine if it works. Currently, in filteredtree, in my
dethreadization branch, a state is represented by a self.cache_nodes and
a self.cache_vr.

The change is now atomic : we switch to a new state in a lock and also
increase a self.state_id counter.

What we could easily do is to simply save those state with their
corresponding state_id.

All the methods would get an additional parameter which would be the
required state_id. If none, the behavior would be the current one (the
latest state_id).

The treemodel will keep the nbr of the state id he's currently in as a
global variable. This variable will be incremented each time a signal is
processed (in my branch, signals already carry the number of the
revision they are announcing).

That means that, if the tree model has in queue the signal 43 and 44 but
they are not processed yet, it will ask the filteredtree the answer at
state 42.  

Given the current code of filteredtree, this would be fairly easy. 

To avoid memory growth, we could simply add a way for the treemodel to
say that a signal has been processed (and thus that we can forget all
the previous states).


This is hackish, ugly and make the liblarch code highly specific (I will
not release a self-standing liblarch which such an ugly workaround)
but :
1. With the current code, it would be fairly easy (albeit a bit long and
boring)
2. Should not impede to much performances
3. Will not require to work with the global lock or anything else (all
of what is needed is already done in my branch).
4. I've already proven in my branch than by setting an higher priority
to the handling of signals in treemodel reduces significantly the number
of errors. (the treemodel listen more to signals and explore less by
itself between them). 

The only bug we would need to solve is to ensure that we have a "one new
state -> one signal" rule. It's not the case when deleting currently.


I wanted to give it a try tonight but I will not be able so I write the
idea to have an external point of view. I'm tired of that and it could
be a workable exit. 


Lionel