Bertrand, any progress on this? And again, as the proposed fix (refactoring the hell out of gtg) seems quite complex, I have to reiterate the question: why not just limit GTG to refreshing the treeview only when the user moves the focus out of the note's title (instead of in realtime), as a stopgap measure?
-- Taskbrowser refresh is way too slow https://bugs.launchpad.net/bugs/351867 You received this bug notification because you are a member of Gtg developers, which is the registrant for Getting Things GNOME!. Status in Getting Things GNOME!: In Progress Bug description: Hey, I recently stumble upon GTG and liked it instantly. Unluckily I have now discovered (after filling 200+ taks via the quick add entry) that it is too slow to be used productively. - Filling the task on startup takes rather long. There should be nothing complicated to it... - Typing a word in the note name row freezes GTG for ~2seconds. The same applies for adding a tag by typing @.. - Filtering of tags takes ~1 seconds, but this should happen instantly I only had a short look at your code and saw threading, locking code and a refresh method. Is that really needed? Often in such simple applications pseudo threads via python generators and gobject.idle_add are more than sufficient. IMHO performance could be improved by several orders of magnitude if you use a proper GTKTreeModel. With this at hand you don't need to care about updating or redrawing your stuff. You should also consider wrapping your file/source abstraction in a custom GTKModel that yields the correct signals when required (not that difficult...) I haven't looked at what happends when you add a tag. But maybe you can only do (what ever you currently do) when I hit enter/linefeed or close the window. Thanks and best Regards, steve-e _______________________________________________ Mailing list: https://launchpad.net/~gtg Post to : [email protected] Unsubscribe : https://launchpad.net/~gtg More help : https://help.launchpad.net/ListHelp
