On 17. des. 2010 03:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Provided that it doesn't introduce regression, it looks good. But I would
rather put a shorter timing here in order to avoid inconcistencies and
crashes
i did already testing before sending the patch and the updateView routine
is pretty robust even when you change the background buffer meanwhile.
(ex: if the user is fast enough to use the outine one second after
typing a char). I am sure you won't feel the difference if you set it to
0.5s.
tried 0.5 and no. writing bit tensed but ok, works. however moving with
cursor makes me still frustrated.
but i understand your concerns about possible inconsistencies.
If I understand right: Performance is increased by delaying update of
the ToC view, and there is worries about what happens if a user
click the ToC before it gets updated?
Simple solution: If the ToC is clicked when it isn't 'ready', ignore the
click event. No damage and the user will simply retry.
Even better: when a not-ready ToC is clicked - update the ToC then and
there. That way you're sure it is ready when the (fast) user retries.
This approach allows arbitrarily long delays, only limited by user patience.
Helge Hafting
