gtg-contributors team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

On Thu, 23 Sep 2010 22:50:58 -0700, Luca Invernizzi
<invernizzi.l@xxxxxxxxx> wrote:
> On Thu, Sep 23, 2010 at 2:03 AM, Lionel Dricot <ploum@xxxxxxxxx> wrote:
>> Could it be an escape way ?
> 
> Great. It's very responsive when loading a lot of tasks when GTG has
> already been started (./scripts/gtg_stress_test), and it doesn't block
> the ui at all. It seems a good way to go!

Mmmm, it smells good !  Even better : it would mean that optimization of
task loading is a lot less critical. If the UI is responsive since the
beginning, who cares if it takse 32s or 43 to load your 1000 tasks ? 

Did I told you that I like the smell of fixed bugs in the morning ?


So, it looks a very promising approach. So far, there are still GTK
crashes but I bet that it's because :

- Some calls in treemodel.py are called by another thread. We simply have
to find them and correct that.
- At some point in filtered tree, we don't have a "signal/state" perfect
match (we send multiple signals at once)
- I wonder if the reordered signal is well called with idle_add. Anyway,
I'm not sure anymore that it's necessary.
- At some point, we also ask for subtasks that are not there yet. I
believe it's mainly due to task.py intercepting some of those calls for no
reason and maybe already considering to have some subtasks when they are
not loaded yet (this can be seen when you start GTG with workview and with
a lot of tasks).
- There's also the question about tree.py being threadsafe itself. I don't
think it is.


Lionel