Previously the whole application core dumped after a finished print or
when a log message was emited from the main thread after the printing
thread wrote into it.
One can only speculate what exactly happened here, but a plausible
explanation seems to be that when the printing thread wrote into the
window as a copy to write was done as the window was accessed.
Essentially moving the ownership into the printing thread. The moment
the original main thread tried to access the window again (e.g. after
closing it, writing to it, ...) everything came down as the state
didn't represent the expected state anymore.
Introducing a qt signal (which are thread safe) solves this problem as
the text field is only accessed now from the thread that created the
window.
Previously the whole application core dumped after a finished print or when a log message was emited from the main thread after the printing thread wrote into it.
One can only speculate what exactly happened here, but a plausible explanation seems to be that when the printing thread wrote into the window as a copy to write was done as the window was accessed. Essentially moving the ownership into the printing thread. The moment the original main thread tried to access the window again (e.g. after closing it, writing to it, ...) everything came down as the state didn't represent the expected state anymore.
Introducing a qt signal (which are thread safe) solves this problem as the text field is only accessed now from the thread that created the window.