Commit Graph

9 Commits

Author SHA1 Message Date
Matti Paaso
974c210835 Update license headers and add new license files
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL

Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
2014-09-24 12:26:19 +02:00
Tor Arne Vestbø
4bae7158d3 Don't send posted events from QWindowSystemInterface::sendWindowSystemEvents
The responsibility of sendWindowSystemEvents() is to process events from
the window system. Historially that logic was part of the QPA/QWS event
dispatcher, which naturally also sent posted events. Through refactoring,
the code at some point ended up in in the QWindowSystemInterface class,
still with the posting of events in place.

This resulted in QPA event dispatchers adopting a pattern of just calling
sendWindowSystemEvents(), as that would cover both posted and window system
events. Other event dispatchers would call sendWindowSystemEvents(), and
then use a base-class implementation from QtCore for processing events,
resulting in two calls to QCoreApplication::sendPostedEvents() per
iteration of processEvents(). This breaks the contract that processEvents
will only process posted events that has been queued up until then.

We fix this entanglement by removing the sendPostedEvents() call from
QWindowSystemInterface::sendWindowSystemEvents() and move it to the
respective event dispatchers. For some EDs it means an explicit call
to sendPostedEvents, while others were already doing sendPostedEvents
though a separate source (GLib), or using a base-class (UNIX/BB), and
did not need an extra call.

We still keep the ordering of the original sendWindowSystemEvents()
function of first sending posted events, and then processing any
window system events.

Task-number: QTBUG-33485
Change-Id: I8b069e76cea1f37875e72a034c11d09bf3fe166a
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
2013-09-16 15:22:40 +02:00
Tor Arne Vestbø
eb614cf7e7 Don't assume processEvents(WaitForMoreEvents) will process timers
The WaitForMoreEvents flag only guarantees that we will process _some_
events -- either if they are in the event queue already, or by sleeping
and then waking up to process an event. This event might be a system
event, not the timer firing, so a single call to processEvents() is
not enough to guarantee that the timer has fired. Instead we do a
Q_COMPARE with a timeout, where we continiously process events until
we see that the timer fired.

Change-Id: I5dc04377f04190f3505be22e877af73d11b7547d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
2013-09-05 02:32:57 +02:00
Sergio Ahumada
48e0c4df23 Update copyright year in Digia's license headers
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
2013-01-18 09:07:35 +01:00
Iikka Eklund
be15856f61 Change copyrights from Nokia to Digia
Change copyrights and license headers from Nokia to Digia

Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
2012-09-22 19:20:11 +02:00
Thiago Macieira
672b5b7ab6 Set the Qt API level to compatibility mode in all tests.
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.

Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
2012-08-01 15:37:46 +02:00
Bradley T. Hughes
8f8e3db6ae Test posted events in tst_QEventDispatcher with various flags
Add QEventLoop::ProcessEventsFlags test data for
tst_QEventDispatcher::sendPostedEvents() to test that posted events are
sent when waiting for events and when not waiting.

Change-Id: I99f9eb121d0b1ded725e19c5233922fc0a6b81e4
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
2012-02-10 15:22:11 +01:00
Bradley T. Hughes
358c14821b Run tst_QEventDispatcher with the GUI event dispatchers as well
Since some GUI event dispatchers are complete reimplementations and do
not build on the corelib ones, we want to run the same tests with the
other dispatcher.

Since this is a GUI test now, we need to make sure to drain system
events queued during application startup to make sure we can reliably
run the test functions.

Change-Id: I4905db70bc8f8584c4ef1f4d767824040281452c
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
2012-02-10 15:22:03 +01:00
Bradley T. Hughes
c50f026a22 Add tst_QEventDispatcher to tests/auto/corelib/kernel
This will test the event dispatcher in corelib for proper timer and
posted event handling. The test makes sure all of the necessary virtual
functions are implemented and working as expected.

This test doesn't test socket notifiers or Win32 event notifiers, as
these are already covered in existing tests.

Change-Id: I5540ffc4e6d7f97bcd6c3725d7e74c0ab9c97015
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
2012-02-10 15:21:55 +01:00