View Single Post
Old 11-14-2019, 01:08 PM   #117
KevinH
Sigil Developer
KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.KevinH ought to be getting tired of karma fortunes by now.
 
Posts: 8,893
Karma: 6120478
Join Date: Nov 2009
Device: many
Just pushed yet another related fix to prevent stale info from ever being left in m_LastContentTab in TabManager.cpp (and to quiet that annoying warning) which became necessary since we moved away form using a guarded QPointer for it.

This now handles the problem.

BTW: debug builds and debug output are really only needed if I can either not recreate the issue or can not get a decent backtrace. In all of these cases of closing tabs too fast, I have been able to recreate things and get good traces. qDebug info would not have helped.

All of these troubles are because QTabWidget::setCurrentIndex() makes a call to Qt's processEvents() **BEFORE** returning which emits the currentChanged() signal before the new state has officially been implemented.

So whenever we add a new tab or remove a tab, we must actually disconnect that signal and manually reconnect it afterwards to prevent the nonsense that Qt is inflicting on us.

This should finally do the trick.

Please git it a try.

KevinH
KevinH is offline   Reply With Quote