gtg-contributors team mailing list archive

[Luca Invernizzi <invernizzi.l@xxxxxxxxx>]

On Tue, Sep 21, 2010 at 7:50 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
> I agree that the development time spent on this is crazy. And it's only a
> "tool".
>
> I've discussed on IRC with some gtk developpers. One really important
> thing to know:
>
> - You always have to be consistent with the signal you send. So, it should
> be "modify node a, send signal, modify node b, send signal".  "Modify a and
> b then send two signals will crash".
> You will think that "but what between the modify and the sending of the
> signal ?" Answer : nothing, as all happens in the same thread !
>
> That's crazy to see how retarded gtk is in this aspect.
>
>
> Hopefully, there's two possible solutions :
>
> 1. Keep a cache with a consistent status for each signal. It means that as
> long as we haven't processed signal 42, all answers should be those of
> state 41.  (that doesn't sound too difficult)
>
> 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).



>
>
> On Tue, 21 Sep 2010 07:38:43 -0700, Luca Invernizzi
> <invernizzi.l@xxxxxxxxx> wrote:
>> 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.
>