C++ Qt5 QWidget paint event “chain reaction” - how to implement without recursion? - c++

Question

Intro:
I am writing an app which displays a list of custom QWidgets (namely, “ScopeWidget”) in a container widget with VBoxlayout (“ScopeView”).
Every scopeWidget has a pointer to an own data source class (“Scope”). These objects are logically arranged in groups, i.e. there are some shared parameters (“ScopeShared”) among objects in one group.
These parameters are needed when retrieving (or preparing) the data which has to be displayed on a scopeWidget.
One step further:
A scopeWidget needs two sets of parameters: these given by “Scope” and given by “ScopeGroup”.
A scopeWidget can, by user action, change some of the shared parameters in a group, thus invalidating all previous retrieved data, held by “Scope“s in this group.
By default, there is no displayable data in a “Scope”. Data is retrieved on demand – when a paintEvent occurs (this is the source of the problem). To get displayable data in a “Scope”, one have to process all “Scopes” in this particular group (which yields usable data for all “Scope“s in the group).
How it works:
The user forces one of the scopeWidgets to change shared data in a group. After making these changes, all data held by “Scope“s in this group, is invalidated, so the change event reprocesses the whole group. And calls update() for all scopeWidgets in this group. Widgets are redrawn. This works…
The problem:
…is a paintEvent which occured spontanously. When the user changes something – I_know that this happened and I can process the scopeGroup prior to enqueuing updates of widgets. But when “something else” (the system itself) executes a paint event, I_need to process the whole group before any painting happens.
So the paint event does no painting directly, but executes scopeGroup processing, and after that, it paints the widget which had the painting event, and calls update() for all other widgets in that group – which in turn causes new paint events, which cause a next scopeGroup processing, one paint(), and update()‘s for other widgets, which causes new paint events – it ends up as recursive repaint (and scopeGroup processing)
Lame solution:
flags – spontaneous paint events do group processing, one paint() for the requesting widget, and update()‘s on the rest of widgets in the group, together with setting flags for every widget.
This pseudocode depicts this mechanism:
paintEvent(QWidget *w)
{
if(w->flag)
{
w->paint(); w->flag=0;
}
else
{
w->group()->process();
w->paint();
QWidget *x;
foreach(x,group) if(x!=w) { x->flag=1; x->update(); }
}
What would be IMHO better:
a) if widgets could be painted without a prior paint event (or call to update() or repaint() )… this would be the best ;], but it doesnt work in the straightforward and obvious way – is there any other way? – or
b) force the system to call a custom function instead the paint event
Are these ‘better’ solutions possible?