Context Navigation

Changes between Version 7 and Version 8 of Ticket #15277, comment 12

v7	v8
10	10
11	11	It appears that the crash is caused by running the graphics update loop before the screen remove callback. It still crashed even if it never drew the graphics as long as it ran the update loop (new frame callback, ...). That is why blocking update avoids the crash because the update loop is not run. Writing log messages to a file shows that the update loop is not called after the remove screen callback when it crashes. So somehow the update loop just before the screen removed callback causes the crash. I included the number of screens in the logged update loop output and the last log entry before the screen remove log entry shows it still thinks it has two screens. So even if I determine what Qt calls in the update loop are leading to the crash it doesn't look like I will have any way of knowing that the screen remove is in process and will cause a crash.
	12
	13	This theory is wrong. If I just comment out view.draw() in the update loop then there is no crash.
	14
	15	Need to investigate more.