| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updating the geometry and available geometry in two steps means that
QScreen will be in an inconsistent state when emitting the geometry
change signal, as the available geometry has not been updated yet.
Piggy-backing changes to the availableGeometry based on the virtual
geometry changing does not make sense, so we now tie geometry and
availableGeometry (and their size variants) to their own separate
geometryChanged and availableGeometryChanged signals.
Change-Id: Iee0ced642cbb91c470cb54bc507d2c0512482c13
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QExposeEvent::region() reports a region in a random coordinate system.
The behavior is undocumented and the platform plugins do different things.
xcb, offscreen and ios are correct. These set the region in local coordinates,
which is the most logical interpretation of the expose region.
windows is almost correct, except for one occurrence.
cocoa and others need changes: passing in geometry() as the exposed region is
always wrong.
The patch documents the expected behavior both for QExposeEvent and
internally in QWindowSystemInterface. The problematic plugins are fixed to
use local coordinates.
Task-number: QTBUG-40470
Change-Id: I6ded3154d14254fa71d4292d8e1b5e6cf696c81a
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, it has been necessary for tablet-oriented applications which
care about multi-button styli to reject each tablet event and wait for
the mouse event in order to know which buttons are pressed. This patch
adds the new API and also the X11/xcb implementation.
[ChangeLog][QtCore][Tablet support] Added buttons to QTabletEvent
Task-number: QTBUG-39458
Change-Id: If2c9ec1ceacc1700a82686c5fc6f568f9111055a
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently a click on e.g. the dock icon is not propagated to the
application so if for example the main widget is hidden, it can't be
brought back. Also neither applicationDidBecomeActive nor
applicationDidResignActive do anything. This patch fixes it
[ChangeLog][QPA][OS X] Add support for ApplicationState capability.
Application can now detect when an application states has changed
as well when the dock icon has been clicked.
Task-number: QTBUG-10899
Change-Id: I53d3e6eed4adc62b343e7aa3e3d8068d3248e7df
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Make sure that resize events are delivered when the platform
plugin overrides the geometry set in setGeometry().
This fixes a race condition where a widget was resized to its
sizeHint() while the window was maximized, and the content was
shown scaled on the screen.
The problem is that the widget gets the wrong size from
QWidget::setWindowState() (which calls adjustSize() in order to support
normalGeometry). This size is used to resize the backingStore. When the
QWindow is resized, it calls QEglFSWindow::setGeometry() which corrects the
size to screen()->availableGeometry(), and triggers a GeometryChangeEvent
since the size was corrected.
This ends up in QGuiApplicationPrivate::processGeometryChangeEvent() which
will not send a resize event, since the size has not changed (it is always
availableGeometry()). Therefore the widget is never resized, and the
backingStore remains the wrong size.
Task-number: QTBUG-34421
Change-Id: Iee49c53cc529de36010db2695d838d8c2284edd4
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
|
|\|
| |
| |
| | |
Change-Id: Ie56539b2e0be611a363b5f15ae5412a78d6945a2
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add QWindowSystemInterface::GestureEvent and
QNativeGestureEvent to QtGui. These events are copies
of Qt4's QNativeGestureEvent, where it was an implementation
detail of QGestureManager.
Add gesture message handlers to QNSView and bring
back the Mac gesture recognizers for QGestureManager.
Task-number: QTBUG-28126
Change-Id: I1304e09e776fa7c44d133d54ca8b895ca2f544c5
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make platform plugins, like the windows one, able to indicate
if a mouse event is synthesized from a touch event by the OS.
This will be valuable information for the Quick2 event handlers.
No new member variables are added to QMouseEvent. Instead, the enum
value is encoded in the caps member, there are plenty of bits
available in it.
This introduces Qt::MouseEventSource and QMouseEvent::source() as
public APIs.
Change-Id: If087a0bafb33a6cd7891bd07b84871358f6aba69
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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>
|
|
|
|
|
| |
Change-Id: I4d8e7d48497d0d96a297191976c0d99feb67b538
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
|
|
|
|
|
|
|
| |
Task-Number: QTBUG-32835
Change-Id: Ifee10d815ce0037c96eda574ab9e1af67ff6bd78
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some platforms (read: OS X) send wheel events without delta to indicate
that scrolling is about to start or has ended. Currently, Qt simply
ignores wheel events that have no delta. This change introduces a new
QWheelEvent attribute that specifies the phase, and makes it possible
to receive the special wheel events in started/ended phases. These
events are required for implementing correctly behaving transient
scrollbars.
Change-Id: Ib8ce0d9ce9be63b2ad60aa7b0aaa1f12ef6cad09
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
|
|
|
|
|
|
|
|
| |
Also implements the Cocoa backend for that.
Change-Id: I32977e12a04e1cf48b12333442482746c69ce133
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
QNSWindowDelegate was not handling windowShouldClose, which is how you
can tell Cocoa that your window should not close if the close button is
pressed. This change moves the close handling from windowWillClose to
windowShouldClose, and adds an optional "accepted" pointer to
QWindowSystemInterface::handleCloseEvent so that QNSWindowDelegate can
return a true/false value for whether the window should actually close
Task-number: QTBUG-28965
Change-Id: I67c6296ad42cbeeb71413e05411467d4e558adb4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a static QWindow::fromWinId(WId id) constructor which can be used to
create a QWindow object representing windows created by other processes.
Then, QWindow::setParent() can be used to embed a window into a foreign
window socket and QWindow::setTransientParent() to stick the current
window on top of a foreign window.
The changes in the QtWidgets module ensure that the focus chain (TAB
navigation) correctly works when a QtWidgets-based window is embedded
into another application.
As far as the platform implementation is concerned, this commit only
implements the embedding functionality in the XCB plugin. So, this is
roughly equivalent to the Qt4 QX11EmbedWidget functionality.
Change-Id: Iff8f7b9ee974d33fb30f36056f7838b433a413c7
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
For platform plugins such as the Android plugin, we need to
make sure an event is delivered and handled before continuing
execution (e.g. when doing an expose event to report that the
EGL surface has been destroyed when the app goes into the
background.)
Change-Id: Ibd381baafa93f111dbc887d4cf9d9ca37429b186
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The motivation for this patch is twofold:
1: we need a way (for iOS/Android) to tell the current window to remove
focus from the focus object when the user hides the input panel.
Otherwise, if the focus object is e.g a line edit, the cursor will
continue to blink inside it, which is wrong. As it stands, telling
the active window to deactivate
(by calling QWindowSystemInterface::handleWindowActivated(0)), will cause
the whole application to deactivate if no windows are active, which
is not what we want.
2: Qt currently understands just two application states, Activated and
Deactivated. On mobile platforms we can have other states
as well, like "suspended" on iOS. So controlling the application
state should not depend on window activation, but instead be controlled
through a separate API by the platform plugin.
This patch will add the following function:
QWindowSystemInterface::handleApplicationStateChanged(Qt::ApplicationState newState)
that lets us control the application state from the plugin. This also
means that we factor out application state handling from window
activation, which also gives us a way to remove focus from a window while
keeping the application active.
To not break existing desktop platforms that relies on application
activation being tied to window activation, we need to make this API
opt-in by using a platform integration capability hint. This is not optimal, but
found necessary after investigating several other solutions.
Which states (other that active/inactive) it makes sense
to add to Qt::ApplicationState will be a topic for later patches.
Change-Id: Ic6fdd3b66867abb67da43eba04ec86f06d82ff94
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
|
|
|
|
| |
Change-Id: Icfc606a49a7fd24fcd35b9c818642a03e044ed6c
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the call to handleFileOpen may receive a non local URL.
With previous API, there was no way to pass it to other layers. With
this change, any platform plugin creating this event can directly pass
a URL.
Change-Id: Ibd7299ad6c09527e1db979840bd67726882efb9b
Reviewed-by: Jose Dapena Paz <jdapena@igalia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
|
|
|
|
|
|
|
|
|
|
|
| |
The macro was made empty in ba3dc5f3b56d1fab6fe37fe7ae08096d7dc68bcb
and is no longer necessary or used.
Discussed-on: http://lists.qt-project.org/pipermail/development/2013-January/009284.html
Change-Id: Id2bb2e2cabde059305d4af5f12593344ba30f001
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: hjk <hjk121@nokiamail.com>
|
|
|
|
|
| |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enter handling requires knowledge of the mouse
position. Extend the enter handling of
QWindowSystemInterface to receive the position
(implemented for Windows, XCB and Mac), passing it
on to QEnterEvent. Dispatch QEnterEvent from
widgets code.
Change-Id: I49c07d2b1f46310c877017dd55d4cd7d636bdbce
Reviewed-by: Miikka Heikkinen <miikka.heikkinen@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Context menu key wasn't working, as QPA had no handling for it.
Added ContextMenu event to QWindowSystemInterface and proper handling
to QGuiApplication and QWidgetWindow.
Also provide Windows implementation.
Task-number: QTBUG-27648
Change-Id: I7ce71ec4b5cdcc7be758e67f9faf6d863f7b19be
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Native widgets have a native window each, so QPA plugin sends enter and
leave events for associated QWindow whenever mouse cursor moves from
one widget to another. QWidgetWindow had no context to interpret these
events as moves from one widget to another, since they were sent
separately. This resulted in leaves and enters for each widget in
parent chain, when only the bottom child should have gotten them.
Fixed by peeking into window system message queue when handling leave
in QWidgetWindow and retrieving the entered window from queued enter
event.
Also provided a convenience function that QPA plugin can use to
ensure both leave and enter events are in the event queue when
moving from one QWindow to another.
Task-number: QTBUG-27550
Change-Id: I74fec0ac90f6848495c2392c5f7e41624ad8aea2
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are now two different ways to implement synchronous
event processing. The platform plugins can choose which
one to use.
1) flushWindowSystemEvents()
Use to flush the event queue at one point, making
preceding calls synchronous.
2) setSynchronousWindowsSystemEvents(bool enable)
Makes all handle* functions synchronous, bypassing
the event queue completely.
Change-Id: I020b80c731fd13f855a377d7c91d06a4e39b6a0b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This event can be used by any platform plugin to implement
special application panels/overlayed menus.
Currently used by QNX only.
This replaces sending fake Qt::Key_Menu presses in the QNX
plugin. Qt::Key_Menu is already used when invoking context
menus with the keyboard.
Change-Id: I9c8f1743fd147a07c11883323800017376915ae1
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Nicolas Arnaud-Cormos <nicolas@kdab.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously synchronous window system events were
implemented by bypassing the queue and processing
the event immediately. This is not ideal since the
event order is not preserved - there might be "happened
before" events waiting in the queue.
Add QWindowSystemInterface::flushWindowSystemEvents
and change all handleSynchronous* to 1) queue the
event 2) call flushWindowSystemEvents.
flushWindowSystemEvents is almost identical to the
already existing sendWindowSystemEvents with the
exception that it does not call QApp::sendPostedEvents.
Move the common implementation to a new private function.
Task-number: QTBUG-20778
Change-Id: Ie98a83875bc0a14e335e36bed0dd9e0ed4a1dea0
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@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>
|
|
As discussed on mailing list and QtCS 2012.
Any file starting with qwindowsystem is now marked as
QPA API.
This change drops _qpa from the filenames and adds gui-private
where required for the code to compile. This change is backward
compatible otherwise and compat headers are created for
the old inclusion headers.
Change-Id: I72ea0f394dee74f46e614fcf11ab5500ac9fef2a
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
|