trying to stop calling into the MainWindow

[K. "pestophagous" Heller]

To Dirk and Tomaz: thank you for starting this untangling! and thank
you for pushing it to master for all to see/comment/fix. i look
forward to it.

On Fri, Nov 6, 2015 at 4:59 AM, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>
> on the other hand, i can probably write a 10 page article (i.e. rant)
> on signals/slots vs callbacks/interfaces.
> but we may have to stick with how Qt is designed...i just don't like
> meta compilers and find the "dispatcher" / "listener" software
> patterns (or whatever they are called) confusing for new people in the
> code base. it creates such a supposedly-ordered-mess that even an
> author can scratch his head at one point "where the heck is this
> signal coming from? is it coming from the S.E.T.I. program?".
>
> lubomir

Lubomir, i would gleefully read this 10 page article.

Speaking as one of these new people in the code base, i confirm your
claim that the broadcast/listener stuff can lead to unintuitive
outcomes.

In case anyone was looking for a concrete example, it happened recently, here:

http://lists.subsurface-divelog.org/pipermail/subsurface/2015-October/022830.html

this part at the bottom:
>> When I click "Apply changes", i end up in MainTab::acceptChanges.
>> From there, the following (and more) happens:
>>
>>   clone_dive
>>   record_dive
>>   MainWindow::instance()->dive_list()->unselectDives();
>>   MainWindow::instance()->dive_list()->reload
>>
>> (MainTab::acceptChanges is a big function, and those four lines are
>> only a small fraction of what it does.)
>>
>> The clone_dive and record_dive calls result in the correct dive being
>> added to the log.
>>
>> PROBLEM: dive_list()->unselectDives() triggers slots, and makes
>> ProfileWidget2::plotDive get called, which calls create_dive_from_plan
>> .... but "displayed_dive" is a totally zeroed-out dive. (it just got
>> zeroed by clone_dive).
>
> I think this is a valid analysis. We had problems at other places when a replot was triggered while in the middle of some operation. For this there is
>
> MainWindow::instance()->graphics()->setReplot(false);
>
> which prevents replotting until called again with true as argument. Could you try to add that around the code you identified in MainTab::AcceptChanges to see if it prevents the warning?
>
> Best
> Robert

IMPORTANT: i am not complaining!  I am merely documenting :)

Another crucial factor contributing to the confusing and "side effect
ridden" outcomes, however, is this:

broadcast/listener pattern is one thing, but using it in *combination*
with globally shared mutable state ("displayed_dive" in the above
example) is really where things get fragile.

/K