Couldn't we split off the 'secondary' update goals (like scrollbar and paragraph style box update) from 'core update' (i.e. metrics + drawing)?
This way no other widget than the main text widget will be touched during the critical phase and no 'spontaneous' Qt events will be passed down to the core. Is this correct?
Who knows? If Qt fires events just because a combobox is updated, who knows what it might do in other cases, or worse, in the future. Maybe someone could ask on a Qt mailing list?
I am not yet convinced that we can't. In the critival phase we are just touching core structures and draw to a single widget.
If that single widget turns out to be a problem nevertheless, we could still go for three-phase-drawing (metrics + null painter + full painter). The critical phase for filling the coord cache would here be only phase 1 and 2, both of with do not have any gui interaction at all. Only the last phase would tocuh a (single) widget, but then the coord cache is in a stable state.
That would be an alternative, although this might be more than a few lines of code to do.
This would mean having our own event queue on top of Qt's... And I thought toolkits were made to relieve developers from re-inventing the wheel all the time. This somehow doesn't feel Right.
Martin already implemented it. It wasn't too bad.
As long as it is commented, I believe Martin's patch is fine. It is the least intrusive patch, and it solves the problem. It's not like we are looking for problems to solve, and Martin's solution is not a hack.
Regards, Asger
