summaryrefslogtreecommitdiffstats
path: root/doc/src/snippets/sqldatabase/sqldatabase.pro
diff options
context:
space:
mode:
authorLuboš Luňák <l.lunak@suse.cz>2010-10-27 14:26:08 (GMT)
committerOlivier Goffart <olivier.goffart@nokia.com>2010-10-27 14:26:08 (GMT)
commit723cd931cc15a3ce075c575f1d08e4586177521f (patch)
tree0d5936dff3fddffb53d70735e45aa390c58b56d5 /doc/src/snippets/sqldatabase/sqldatabase.pro
parentd9cc9d959a4f177656d5c13725529e9877da3b30 (diff)
downloadQt-723cd931cc15a3ce075c575f1d08e4586177521f.zip
Qt-723cd931cc15a3ce075c575f1d08e4586177521f.tar.gz
Qt-723cd931cc15a3ce075c575f1d08e4586177521f.tar.bz2
fix QEventLoop::X11ExcludeTimers with Glib event loop
When GSource prepare or check functions return TRUE, Glib does not necessary call the dispatch function immediatelly (probably depends on the ordering of processing events). This means that timerSourceDispatch() may get called from different call of QEventDispatcherGlib::processEvents() than its accompanying timerSourcePrepareHelper() or timerSourceCheckHelper(). This is a problem if a timer becomes pending during a normal processEvents() call but will only be executed during a call to processEvents() with QEventLoop::X11ExcludeTimers. The attached patch fixes this problem by rescheduling the timer for another pass. As for a testcase, this happens when making LibreOffice's KDE integration use Qt event loop, requires setting the useEventLoop property on the QClipboard object, so I'm afraid I don't have anything simple. But fact that Glib can keep an event pending for a little moment is rather obvious from its sources or can be triggered from any Qt application, and I hope the rest is an obvious consequence. Merge-request: 2492 Reviewed-by: Olivier Goffart <olivier.goffart@nokia.com>
Diffstat (limited to 'doc/src/snippets/sqldatabase/sqldatabase.pro')
0 files changed, 0 insertions, 0 deletions