On Thu, 23 Sep 2010 22:50:58 -0700, Luca Invernizzi <[email protected]> wrote: > On Thu, Sep 23, 2010 at 2:03 AM, Lionel Dricot <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~gtg-contributors Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg-contributors More help : https://help.launchpad.net/ListHelp
