| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Diff generated by running clang-tidy's modernize-use-nullptr checker on
the CMake-based Qt version.
Skipping src/3rdparty, examples/, tests/
Change-Id: Ib182074e2e2fd52f63093f73b3e2e4c0cb7af188
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a better solution for fbb485d4f6985643b27da3cc6c5b5f960c32e74d.
The existing solution was working fine, but it was exposing logic that is
internal to QWindowSystemInterface and platform plugin interaction. Some
platform plugins do event filtering at native event level - those that
support QAbstractEventDispatcher::filterNativeEvent(). Other plugins rely
on QWindowSystemInterface to do the filtering. Dispatchers should not care
about this.
The new logic rely on the fact that QWindowSystemInterfacePrivate::handleWindowSystemEvent
calls QAbstractEventDispatcher::wakeUp(). The same way postEventSourcePrepare()
rely on QCoreApplication::postEvent() to call QAbstractEventDispatcher::wakeUp().
Event sources run in the order they are attached, postEventSourcePrepare runs
before userEventSourcePrepare(). We rely on that order to pass wakeUpCalled
value.
Change-Id: I0327f4f2398fd863fb2421b8033bb1df8d65f5af
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 341bfcd1eaa9116c143e3b7d3219ef04c7b8a0cb.
As it turns out there might be use cases where we want to have proper
windowing system event integration with glib dispatcher via g_source_attach().
For example with gtk_dialog_run, where GTK blocks in a recursive main loop.
We want to continue dispatcing our windowing system events during this nested
event loop. Not having a proper glib integration can result in rendering issues,
e.g. when resizing parent window via mouse while GTK-based dialog is shown. Can
be seen on examples/widgets/richtext/textedit/ -> Format (from menu) -> "Color..."
The issue from 341bfcd1eaa actually should be fixed inside XCB platform plugin,
by improving integration with event dispatcher. That is handled in follow-up patches.
Change-Id: Icabc6d841a554aefbdd460765a3165d22e65f651
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some Pointer Input messages are defined only for Windows 10 and new
versions of the Windows SDK and could break compilation with older
SDKs. Currently, they are not used anywhere outside of the
MessageDebugEntry debug function. Checking if they are defined before
using.
Change-Id: I5fc7bb8e52ab8aca66bb21084289ab8938938063
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Add it to configure.json and replace all occurrences of QT_NO_THREAD
with QT_CONFIG(thread). Add conditions for other features that depend
on thread support. Remove conditions where we can use the QMutex and
QThreadStorage stubs.
Change-Id: I284e5d794fda9a4c6f4a1ab29e55aa686272a0eb
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
|
|
|
|
|
|
|
|
| |
QUnixEventDispatcherQPA has no private class, there is no need to
declare a fake one.
Change-Id: I615304709fbbea83f6747bb6202dbfd2cc03256d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
|
|
|
|
|
|
|
|
| |
Easier than renaming it with a "qt_" prefix everywhere it's used
(it's in a lot of plugins).
Change-Id: Ie01831ddac5446fdbdeefffd15468918f3bc2238
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
|
|
|
|
|
|
|
|
|
|
| |
Replaces the handling of tablet/touchscreen/touchpad/mouse input with a
unified implementation based on the Windows Pointer Input Messages added
to Windows 8. The legacy implementation is still used for Windows 7.
Task-number: QTBUG-60437
Change-Id: I0a0f48ee9d5365f84ba528aa04c6ab1fe4253c50
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add more message codes and fix the whitespaces in the output:
EVENT: hwd= 0x280484 WM_WINDOWPOSCHANGED msg=0x 47 et=0x 21e wp= 0 at -2208 -31887 handled= false
->
EVENT: hwd=0x2204d6 WM_WINDOWPOSCHANGED msg=0x47 et=0x21e wp=0 at -3280,-19633 handled=false
Change-Id: I89a7b3bd328748ef39fe2dcd789497f43e9d4a2a
Reviewed-by: Andre de la Rocha <andre.rocha@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remaining uses of Q_DECL_OVERRIDE are in:
src/corelib/global/qcompilerdetection.h
src/corelib/global/qglobal.cpp
doc/global/qt-cpp-defines.qdocconf
(definition and documentation of Q_DECL_OVERRIDE)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: Ib9b05d829add69e98a86238274b6a1fcb19b49ba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... when QCoreApplication::processEvents() returns. This is the expected
behavior according to the documentation. Checked also the QUnixEventDispatcherQPA
dispatcher, which did work according to the documentation.
The sequence of events that causes the bad behavior:
1) XCB plugin sends a signals whenever there are new XCB events available
for processing. This signal is connected to QXcbConnection::processXcbEvents,
which will cause XCB events to be added to the QWindowSystemInterface (QWSI) event
queue.
2) When QCoreApplication::processEvents() is called, glib event dispatcher does
one iteration on all attached event sources. First it checks which sources are
ready, and after that starts dispatching events from each source that reported
to be ready.
3) In the case when there are no events in QWSI event queue, the source that handles
QWSI event dispatcing returns 'false'; If at the same iteration the source that
sends posted events (via QCoreApplication::sendPostedEvents()) has returned 'true'
and one of the posted events is to call QXcbConnection::processXcbEvents (due to
signal from step 1) then we get an assert in the following code:
QCoreApplication::processEvents();
Q_ASSERT(QWindowSystemInterface::windowSystemEventsQueued() == 0);
This happens because QXcbConnection::processXcbEvents has posted new events, but
they were not dispatched in this iteration. They would be dispatched in the next
iteration. Events being dispatched on subsequent iteration doesn't really matter
for Qt application, but is inconsistent from API point of view. If we were
populating QWSI queue from non-Gui thread, then it would be possible that
windowSystemEventsQueued() != 0, but that is not the case on XCB (don't know
about other platforms).
The issue could be fixed by always returning true from "check source" and then
simply dispatch 0 events at "dispatch" step if there isn't any in the queue. But
a better solution is to remove the event source all together. It is completely
unnecessary to have this indirection, when we can handle QWSI event dispatch
directly from Qt (like we do, for example, in QUnixEventDispatcherQPA and
QWinRTEventDispatcher). Not having Glib event source for QWSI events would have
also avoided issues that were fixed by fbb485d4f6985643b27da3cc6c5b5f960c32e74d.
Note, after this re-factoring QWindowSystemInterface::nonUserInputEventsQueued is
now unused, but I left it in as the API by itself is all right.
Task-number: QTBUG-62297
Change-Id: Ia245b835676bd87e63bf02b67036b42a3b1593cc
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.. when running event loop with QEventLoop::ExcludeUserInputEvents.
In a properly functioning code, g_main_context_iteration is expected
to block until any event source becomes ready to dispatch an event
(or interrupt occurs). Qt provides several custom event sources to
the Glib event loop. The bug (busy loop) was caused by faulty event
source implementation when QEventLoop::ExcludeUserInputEvents is set.
As long as the window system's event queue was not empty, we signaled
to the event dispatcher that there is an event ready to be dispatched.
This results in the dispatcher calling the relevant dispatch function
(which does handle the ExcludeUserInputEvents flag correctly). As we
do not dispatch user events, the window system's event queue never
becomes empty and we enter a busy loop (CPU running at 100%) where we
signal that we have events to dispatch, but we actually do not dispatch
them and g_main_context_iteration never gets to block.
This busy loop can cause blocking GTK functions such as gtk_dialog_run()
never return.
Task-number: QTBUG-59760
Task-number: QTBUG-57101
Change-Id: I545b7951108eeaba019614ae8f5a1168c8b26c27
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Gunnar Sletta <gunnar@crimson.no>
|
|
|
|
|
|
|
|
|
|
| |
lumping together all kinds of unrelated stuff has caused problems with
spurious dependencies from the beginning. as the modularization infra is
now in a state which supports many small private libraries just fine,
take advantage of it.
Change-Id: Ic40f47ce76a308bbfd32deae281f6f064fe1ef4c
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
|
|\
| |
| |
| | |
Change-Id: I41ee7b50534b01cf042bed8bb8824ba2e5026a29
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use the new qtConfig macro in all pro/pri files.
This required adding some feature entries, and adding
{private,public}Feature to every referenced already existing entry.
Change-Id: I164214dad1154df6ad84e86d99ed14994ef97cf4
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
| |
| |
| |
| |
| |
| |
| |
| | |
this migrates the cases where the build system already made (some) use
of variables (possibly) set by configure.
Change-Id: I43a08caed481d5f887a3a40821e71a4797760e7e
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|/
|
|
|
|
|
| |
Fix the occurrences where the wrong classes are mentioned.
Change-Id: Ia291af77f0f454a39cab93e7376a110c19a07771
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
|
| |
Remove remaining CE-specific files and #ifdefs.
Change-Id: I407e14cade64c9eaa414f333764b4f82a75befde
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
|
|
|
|
|
|
|
|
| |
Most libs use QMAKE_LIBS/CFLAGS, but some have other naming
conventions. Unify them into using QMAKE_LIBS/CFLAGS.
Change-Id: I39b188adc1f9a223a83b294c5315c3095a9c68de
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
| |
This makes it possible to reuse it for the minimalegl QPA plugin.
Change-Id: I1c3dbaf67f32294a5d0e03cc1eb8557049b810a5
Reviewed-by: Oliver Wolff <oliver.wolff@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Export it for use by the iOS platform plugin. Also
move QCFSocketNotifier, and export for use by the
Cocoa platform plugin.
This is a pure code move with no intended behavior
changes, in anticipation of using the Core Foundation
event dispatcher as the default Qt Core event dispatcher
on OS X.
Change-Id: I43677d2f6f3c1d0ed0415c964225aa97d2f13078
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
In anticipation of moving it to QtCore.
The call to QWindowSystemInterface::sendWindowSystemEvents() has been
moved to QIOSEventDispatcher by making processPostedEvents() virtual.
Change-Id: I9e03be4153a9f5f34e9a0ac942cdff572a44c318
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the case of calling processEvents with WaitForMoreEvents and ending up
processing a Qt timer, we explicitly interrupt the runloop, as CF doesn't
normally treat handling timers as having handled a source. That way we
can re-evaluate whether processEvents should return.
But, we need to compute eventsProcessed before breaking out of the
Q_FOREVER loop, otherwise processEvents will return false when
waiting for events and processing a timer.
Change-Id: Ie5f8905228cce1508b5b2e040cf1186820855191
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@theqtcompany.com>
|
|
|
|
|
| |
Change-Id: Ibebe1318d1c2de97601aa07269705c87737083ee
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
| |
Done automatically with clang-modernize on linux
(But does not add Q_DECL_OVERRIDE to the function that are marked
as inline because it a compilation error with MSVC2010)
Change-Id: I2196ee26e3e6fe20816834ecea5ea389eeab3171
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
|
|
|
|
| |
Change-Id: I7a4dd22ea3bcebf4c3ec3ad731628fd8f3c247e0
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
| |
Change-Id: I7dbe938bff5ac3ab50a0197f94bdb2f6c22fbd16
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Mitch Curtis <mitch.curtis@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our previous event loop integration had two unfortunate flaws:
1. We would call qt_user_main() from a timer, after returning from
didFinishLaunchingWithOptions. This had the effect of showing the
iOS application window long before the Qt application UI had been
set up, resulting in a 1-2 second flash of black/pink between the
launch image disappearing and the actual application showing.
2. We spun a nested event loop, where our implementation of the
different event loop modes did not perfectly match the Apple
implementation. This resulted in scrolling being busted in
some cases such as when showing the virtual keyboard for
Emoji characters.
These two issues have now been solved by calling the user's main()
from didFinishLaunchingWithOptions. Normally this would not work, as
the user's main would call QApplication::exec() at the end of their
main(), which would block and we would never return back from the
didFinishLaunchingWithOptions callback, resulting in no UI on screen.
We work around this by longjmp'ing out of QApplication::exec(), back
into didFinishLaunchingWithOptions, so that it can return. Again,
this would normally not work, as the call stack where QApplication
and friends would live would get smashed as the application
continued executing. We work around this by allocating a block
of stack space at the start of main(), which we then redirect the
stack pointer to before calling the user's main. This results in
the whole stack of the user's main() and below being preserved, even
if we longjmp out of the call stack (which then restores the
stack pointer).
This approach should work fine together with garbage-collection as
well, since the mark-and-sweep phase will walk the stack from the
stack pointer to the stack base, including sections of the stack
that were part of qt_user_main() and live in the reserved area.
One case where GC will fail though is if it happens as part of the
qt_user_main() call, where the GC will not mark anything in the
'real' callstack below UIApplicationMain(), but this is not
expected to happen.
The size of the reserved stack can be controlled through the
Info.plist key 'QtRunLoopIntegrationStackSize', as well as the
'QtRunLoopIntegrationDisableSeparateStack' key to disable the
separate stack approach completely. This will fall back to the
old approach. The amount of stack space used by the user's
main can be determined by enabling a special debugging mode,
using the 'QtRunLoopIntegrationDebugStackUsage' key.
Change-Id: I2af7a6cfe1a006a80fd220ed83d8a66d4c45b523
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
As we're using CFRunLoopIsWaiting() to check for the possible presence
of system events hasPendingEvents() will never return false if called
on the main thread. We assume clients will not use this function to
determine whether or not to call processEvents(), but instead use the
return value from processEvents.
Change-Id: Ifd63892c6d35bb7da204072616bfe3ee69ca1d85
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
UIKit changes the run-loop mode during scrolling to UITrackingMode, which
presumably prioritizes touch events and other sources related to a
smooth scrolling experience. It signals this change by interrupting the
current run-loop pass, and the outer loop is responsible for re-entering
the run-loop in the new mode. Failing to enter the run-loop with this
new mode results in UIScrollViews losing their kinetic feel when
flicking. This can be observed by e.g. bringing up the Emoji keyboard
and scrolling it horizontally.
We keep track of the current run-loop mode by listening for push and pop
notifications on the UIApplication object. The current mode is then used
in our Q_FOREVER-loop when re-entering CFRunLoopRunInMode.
For now we don't add our posted event source or timer source to the
new modes, under the assumption that the system prefers to limit the
number of sources that will fire during scrolling. If this turns out
to give a bad user-experience for Qt applications we should consider
changing it.
Change-Id: I3a612b3cfc77c74b658963057732dc4d61684df8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having separate code-paths for QEventLoop::EventLoopExec
and the non-blocking processEvent() we now have a single Q_FOREVER
loop where the logic can be shared. We make multiple loop-passes,
each time calling CFRunLoopRunInMode with potentially different
arguments, depending on the result of the previous run.
For the EventLoopExec case we'll continue making loop-passes until
the event-loop has been interrupted. For the non-EventLoopExec case,
we respect interruption, but will continue making loop-passes only
until we've processed all events in the queue, optionally waiting
for the initial event if WaitForMoreEvents is set. Limitations in
the CoreFoundation APIs unfortunately force us to keep some state
on whether or not we've processed events and timers for a given
processEvents() pass (with corresponding deferred scheduling of
timers and event source signaling).
The way we handle timers has also been rewritten to no longer defer
the timer activation to a special timer source. The constraint of
CoreFoundation timers is that they can not recurse (re-fire) in a
callback, but that only applies per timer, so using multiple CF
timers allows us to recurse. We still only use a single CF timer
for all the Qt timers though, and only spawn a new CF timer if
the user calls processEvents() inside a timer callback.
This commit removes the logic related to dealing with UITrackingMode,
as that logic was slighly problematic, but the feature will be
added back in a follow-up commit, in line with the new approach.
The result of this commit is that we're passing all event-loop,
event-dispatcher, and timer auto-tests, both for the QtCore dispatcher
and the GUI event-dispatcher.
Change-Id: I3c56fbc7857a25110064681257abb47075b5bd2d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
| |
This approach follows the same one used by the Cocoa event dispatcher.
Change-Id: I2813b09beae07d90477c9ca506924058ace13f34
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
| |
Change-Id: Ie9ae40e3f7e2631c461ad01b6e5a4640c0b773c9
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
| |
Change-Id: If34953b171676f0246c2fb5e60c59f59350863ec
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Now that it lives in QPlatformSupport, will be fleshed out more, and
might be used on OSX at some point in time. Still iOS specific, as
none of the iOS API usages have been ifdef'ed.
Change-Id: Ib7fde6403ef2dfef175a6f306a85d58027569a30
Reviewed-by: Ian Dean <ian@mediator-software.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The previous implementation of the nested runloop was derived from the
Mac Cocoa implementation(?), and did not correctly deal with UI
animations and other UIKit functions which are run in a different mode
to the default mode. This version corrects that (in most cases) and
switches the implementation to use CoreFoundation instead of NextStep
APIs.
Change-Id: I45802d22044465749a1e5b6207d745268f6ae8a1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
|
|
|
| |
Move iOS event dispatcher from platform plugin to platform support, so
that it can be used by multiple iOS platform plugins.
Change-Id: I9041b2de5e00e5fe8f30af2dfd922b4f5c594802
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
|
|
| |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
| |
Change-Id: I6bc47f12e60bfbda60e3f242d3b680d5684903ea
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
|
|
|
|
|
|
| |
Change-Id: I0abaf73d4b6b96dbcf499ea86749ced76348c281
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Instead of assuming that all events should be handled when
a user event occurs, userEventSourceDispatch has to use the
flags used in QPAEventDispatcherGlib::processEvents.
Task-number: QTBUG-27595
Change-Id: Ib13607f89f7d3207ec83ab26f7d59b3c59a28c4e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, qEmergencyOut() is now completely exception-free.
Incidentally, this patch shows that Qt isn't consistent in how it
treats empty environment variables used as flags, but that is something
for a separate commit. This patch aims to be behaviour-preserving,
except in exceptional circumstances, of course.
Change-Id: Ie106e7b430e1ab086c40c81cc1e56cd0e5400cb4
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 784a877d3cd9a1a75aca9c83146389503a966071.
Conflicts:
src/plugins/platforms/cocoa/qcocoawindow.mm
src/testlib/qtestkeyboard.h
src/testlib/qtestmouse.h
src/testlib/qtesttouch.h
Change-Id: Iebfed179b3eb7f30e4c95edcae5a8ad6fd50330e
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
| |
No need to pass the dispatcher. Get rid of Windows logic to maintain
a stack of dispatcher associated with flags.
Change-Id: Ic2daad4b6762a46fac3274937effc188af436c9a
Reviewed-by: David Faure <faure@kde.org>
|