This also reverts commit 018e670a26.
The change was introduced in 5.6. After the refactoring, 14960f52,
in 5.7 branch and a merge, it is not needed any more.
Conflicts:
.qmake.conf
src/corelib/io/qstandardpaths_mac.mm
src/corelib/tools/qsharedpointer_impl.h
tests/auto/widgets/itemviews/qlistview/tst_qlistview.cpp
Change-Id: If4fdff0ebf2b9b5df9f9db93ea0022d5ee3da2a4
... by replacing them with C++11 range-for loops.
The function QObject::children() returns by const-reference,
so they can be passed to range-for without further changes.
Change-Id: I8cd2921165c45020914dd3a23b1f18b519fe7900
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
... by replacing them with C++11 range-for loops.
This is the simplest of the patch series: Q_FOREACH took a
copy, so we do, too. Except we don't, since we're just
catching the return value that comes out of the function
(RVO). We can't feed the rvalues into range-for, because
they are non-const and would thus detach.
Change-Id: I457942159015ff153bdfc6d5f031a3f0a0f6e9ac
Reviewed-by: Gunnar Sletta <gunnar@sletta.org>
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Move code from QWidget::setMask() and reimplement QWidget::setMask()
using QWindow::setMask().
Task-number: QTBUG-50938
Change-Id: I040688d6b18df91368fa6ab6392a3b4cd80f2683
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
Reviewed-by: Paul Olav Tvete <paul.tvete@theqtcompany.com>
This reverts commit 4c71db7567.
It's too risky for 5.6, we should let it cook in dev for a while
and backport when ready.
Change-Id: I91e677e65d967f29c84a254cd3dffc8bb847b263
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Resetting focus_window and other internal QGuiApplication variables before
calling setVisible(false) and destroying the platform window means that the
platform window can't reason about whether or not it was the focus window
unless it can resolve that using native APIs. We should let the platform
window take care of resetting the focus window and related states, and
only execute our fallback logic if the plugin doesn't do the right
thing.
We also use QPA to update the state instead of modifying the internal
QGuiApplication variables directly, so that events and signals are
emitted as a result of the reset.
The QLineEdit test gets two added calls to processEvents(), since
assuming that activateWindow() is synchronous is not correct, and
would result in the QMenu resetting the focus window to 0 on destroy.
Task-number: QTBUG-46414
Change-Id: I562788393ed0ffd77d7a4be2279862322f721c1a
Reviewed-by: Błażej Szczygieł <spaz16@wp.pl>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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 is a partial revert of eaa3a9d010
Task-number: QTBUG-50081
Change-Id: Ic3dc4daa90d7a968a4ebf45d3029c99a12985686
Reviewed-by: Shawn Rutledge <shawn.rutledge@theqtcompany.com>
If, after checking a condition, we issue a qFatal()
or a qCritical(), by definition that check is
unlikely to be true.
Tell the compiler so it can move the error handling
code out of the normal code path to increase the
effective icache size.
Moved conditional code around where possible so that
we could always use Q_UNLIKELY, instead of having to
revert to Q_LIKELY here and there.
In some cases, simplified the expressions newly wrapped
in Q_UNLIKELY as a drive-by.
Change-Id: I67537d62b04bc6977d69254690c5ebbdf98bfd6d
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
This information is already registered by the QMessageLogger ctor.
Where, by dropping the << Q_FUNC_INFO in ostream-style qDebug(), only
a string literal remained, converted to printf-style qDebug() on the
go.
Change-Id: I3f261c98fd7bcfa1fead381a75a82713bb75e6f3
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
As a follow-up to 352c357e6f enabling
support for multiple evdevtablet plugins at runtime (one per device),
we also need to adjust the way QGuiApplication handles the events
received from those plugins, in particular when multiple devices
are sending tablet events concurrently.
Replace the static members in QGuiApplication by a vector storing
the same data per-device, so tablet press/release events can be
recognized independently.
Change-Id: Ie0975cdb03a8f6d05903e2e2e57ceb9de73a74a4
Reviewed-by: Jake Petroules <jake.petroules@theqtcompany.com>
When a child QWindow is shown by calling setVisible(true), we don't need to
create the platform window immediately if the parent window hasn't been
created yet.
We defer creation until the parent is created, or we're re-parented into
a created parent or made top level.
This optimization is more important now that we create the full parent
hierarchy once we decide that we need to create a child QWindow.
Change-Id: Ia4f0430f0d3709a12f41f6473c1cea6b0ef3c9cd
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
If the QWindow has been created and has a platform window, we need to
ensure that the windows in the parent hierarchy also are created before
we set a new parent on the platform window, otherwise the platform window
will think that it's a top level window.
Change-Id: Icb2c3cd5411cd1eb595e8673e144095feda31df9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
To be able to create a platform window for a given QWindow we need to
sync up the parent hierarchy first, so that the newly created window
can be placed into that hierarchy.
Without creating the parent hierarchy first, the QPlatformWindow will
end up thinking it's a top level window, when in reality is represents
the platform backing of a child QWindow.
Change-Id: I2cad7759fbc118b04718e7a27ec7570ce1238757
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
We expect createPlatformWindow() to return a valid platform window. If
it fails we now assert in debug, and emit a warning in release. The only
platform where this is currently possible is on Windows, where the
platform plugin will return 0 if CreateWindowEx for some reason fails.
Change-Id: Ia2461efcfc48d180e073fa372d9c385650129e1c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
We initialize the variable d at the top using Q_D(const QWindow);
Change-Id: I2de3b33c043024c5599b7cd1ebecae2db0b39d87
Reviewed-by: Christian Stromme <christian.stromme@theqtcompany.com>
QWindow keeps track of whether a position has been explicitly set by use
of a flag positionAutomatic which gets set in setGeometry. This is used
to determine if position is passed to the window manager.
However calls to setX, setY via properties did not update this flag if
the caller is setting it to the default position 0,0. This patch fixes
that by making sure the flag is always updated.
Change-Id: I2c0c002fe57efa101b3ca79e6e8b3f36cc465761
Reviewed-by: Kai Uwe Broulik <kde@privat.broulik.de>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
qwidget.cpp:12864:70: error: cast from type ‘const QWidget*’ to type ‘void*’ casts away qualifiers [-Werror=cast-qual]
Change-Id: I7de033f80b0e4431b7f1ffff13f956cb26108af7
Reviewed-by: Martin Smith <martin.smith@digia.com>
Add a coordinate scaling layer to QtGui, which supports 'devicePixelRatio'
type high-dpi on all platforms, in production and also for
development and testing purposes.
High-DPI scaling is opt-in, by setting environment variables:
QT_SCALE_FACTOR - sets a global scale factor
QT_AUTO_SCREEN_SCALE_FACTOR - sets per-screen scale factors,
where the scale factors are provided by the platform plugin.
This QtGui scaling can be used instead of or in addition to scaling
done by the window system. This distinction is not visible to
applications [when they use Qt API], which will see a change in
the value returned by the devicePixelRatio() accessors as usual.
Introduce a new (private to Qt) coordinate system: native pixels.
The coordinate system stack now looks like:
device-independent pixels (app, upper parts of Qt)
native pixels (lower parts of Qt Gui, platform plugins)
device pixels (backing stores and OpenGL)
Add private QHighDpi namespace with scaling functions that convert
between device-independent pixels and native pixels:
T toNativePixels(T, QWindow *);
T fromNativePixels(T, QWindow *);
Add scaling calls the QWindow (and friends) cross-platform implementation,
around the calls to QPlatformWindow functions. QPlatformWindow now uses
native coordinates - platform code remains largely unchanged since native
coordinates are window system coordinates.
QWindow now uses (possibly) scaled coordinates. This means that
platform plugins no longer can rely on QWindow::geometry() and
related functions. QPlatformWindow::windowGeometry() and other
convenience functions have been added for use when the platform
plugin needs to convert scaled geometry to native geometry.
Add Qt::AA_NoHighDpiScaling, which can be use to disable any
scaling in QtGui, effectively ignoring the environment variables.
(Note that this does not disable any scaling done by the window
system.)
Contributions from Friedemann and Paul.
Task-number: QTBUG-46615
Change-Id: I673bbd69c130e73b13cce83be11bfb28f580bf60
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
Document that fact that for non-create()'ed windows this is the
same as QGuiApplication::devicePixelRatio() which is the highest
dpr in the system. This has consequences when running with multiple
displays so application developer's have to be aware of this.
Change-Id: Ic05a18732ff021659da04428cb49421ac3453870
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Until now we applied the geometry in QWidget::setVisible() by
calling QWidget::move() and QWidget::resize(). But these
methods are unreliable when the window is created but not
visible yet. For example, specifying the window position by
"-geometry +0+0" will take no effect.
Apply the geometry directly to QWindow in QWindow::setVisible().
QWidget will update its geometry after the response of the window
system. Besides it allows to specify the geometry for QML
applications.
Task-number: QTBUG-44713
Change-Id: I9a0e110e81e569c81da802729707fec104fef887
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
The operators can be switched to verbose using QDebug::setVerbosity()
and then provide more useful information than the standard
operator for QObject.
[ChangeLog][QtCore][QDebug] When streaming QWindow, QScreen,
QWidget instances to a debug stream that has increased verbosity
set, detailed information about geometries, states etc. will
be printed.
Change-Id: Ice26e00f6c713cd6244e1c1df54195e0b0de3c20
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
In addition the logic in QGuiApplication that picks the target window for input
events with a null window has to be enhanced to be compatible with how real windowing
systems work: mouse events following a press are delivered to the same window until the
release, even if the cursor has left the original target window.
Task-number: QTBUG-44814
Change-Id: I3fea84ac77a5ccebeae5def64f92d8d2e03d13ff
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
After change f4b8697c40, it is normal
on X11 to have a null screen when all outputs have been disconnected
or turned off.
Change-Id: I97eeefd86d97701be50f0757fe5c53ca36d79aaa
Reviewed-by: Harri Porten <porten@froglogic.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@theqtcompany.com>
We must do something when requestUpdate() is called on a QWidgetWindow.
The semantics of UpdateRequest for QWindow and QWidget are unfortunately
different: for widgets an UpdateRequest means "sync the backing store".
For QWindow it also involves marking as dirty.
Change-Id: Idf40b3fc0873652dc081edeb12c96b3007a126ef
Reviewed-by: Morten Johan Sørvig <morten.sorvig@theqtcompany.com>
Reviewed-by: Jørgen Lind <jorgen.lind@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>
Don't crash; restore windows when all screens are removed and re-added.
xcb: on configure notify, check for screen change: it may be that a
window belonging to a screen which was removed has now gotten mapped
to the new screen. On screen change, send a synthetic expose event,
because the real expose events already happened.
Task-number: QTBUG-38326
Task-number: QTBUG-32973
Task-number: QTBUG-42985
Change-Id: If334f55c248468ad3c95e7066bb14eca377d2050
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
For windows that were shown on an external screen (not a virtual sibling
of the primary screen), eg. on iOS, it doesn't make sense to re-show the
window when moved back to the primary screen.
By moving the logic into the QScreen destructor, we ensure that the code
path is hit both for the old and unsupported style way of destroying
QPlatformScreen by deleting it directly, and the new and safe way
of using QPlatformIntegration::destroyScreen(), while still allowing
clients to manage the windows themselves by emitting screenRemoved()
before applying our fallback logic.
[ChangeLog][QtGui][Important Behavior Changes] QWindows will no longer
be re-shown automatically when moved from a destroyed QScreen, unless
that QScreen was a virtual sibling of the primary screen.
Change-Id: If1105bc5ef41a5392854bb97d121c998bffa3606
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
Behavior will agree with the docs.
[ChangeLog][QtGui][QWindow] lastWindowClosed will be emitted even if
quitOnLastWindowClosed is not set
Task-number: QTBUG-32956
Change-Id: I7bb269d53894859fee27e171eea7ad472ea86af0
Reviewed-by: Jørgen Lind <jorgen.lind@theqtcompany.com>
Add a virtual function QWindowPrivate::closestAcceptableGeometry()
which is called from the platform plugin.
Task-number: QTBUG-36220
Task-number: QTBUG-36318
Change-Id: I2b3d205e2c75f1d4dd2ba1d333b0d89bc0fcf13a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com>
These synchronously delivered events allow applications to correctly
and conveniently handle native platform surfaces being destroyed. This
is particularly useful when doing rendering on a non-gui thread as it
allows to shutdown rendering before the native surface gets destroyed
from under us.
Task-number: QTBUG-42476
Task-number: QTBUG-42483
Change-Id: I63f41bbdb32f281d0f3b8ec2537eb2b0361f3bb3
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
When QWindow::alert() is called with a duration of 0, it calls
QPlatformWindow::setAlertState(true), and expects the alert state to be
reset when the window is next activated. Other calls to alert are
ignored while alertState is still true.
If alert was called for an active window, it would remain in the alert
state until deactivated and activated again, and on some platforms calls
to alert would be broken while deactivated.
Alerting doesn't make sense for active windows, so we can simply ignore
it, which was the behavior with Qt 4 on some platforms.
Change-Id: Ia3324da4c89db711b63eb31cddf0bf742bb4e3b8
Found-By: Jan Noertemann <jan.noertemann@uni-dortmund.de>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Martin Gräßlin <mgraesslin@kde.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Change 9c3a58a913 causes any window to
be re-created when the screen it is shown on is destroyed. This
is for the use case of detaching one monitor while another remains.
In QWindow::setScreen(), if the screen is null, it will be set to
the primary screen. However during application shutdown, it may be
that the primary screen has been destroyed before all the windows
are destroyed; so trying to set it anyway will cause a crash.
qtdeclarative/tests/auto/quick/qquickwindow was segfaulting,
especially when running testWindowVisibilityOrder by itself.
Change-Id: Ice6b30320ac563f0c70264aa5c57de21d2e4d56e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
When setting a new screen, the code calls QWindow::destroy(), which
recursively destroys all child windows. It then calls create() on the
top-level window, leaving child windows destroyed. This causes crashes
if you have embedded native widgets.
Task-number: QTBUG-40817
Change-Id: Iaace2589f48bbfd5faaf5ff95357ff43b310504a
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Add defaultFormat() and setDefaultFormat() statics to QSurfaceFormat.
These define the default values for the requestedFormat members of
QOpenGLContext, QWindow and QOpenGLWidget (and implicitly QOpenGLWindow,
QQuickWindow, etc.)
This replaces QQuickWindow::setDefaultFormat() which can now be removed.
The main inspiration here is not the convenience (avoiding setFormat() calls
for all windows/widgets), but robustness: by setting the format once at the start
of the application, all windows and contexts, including the internal share context
used by QOpenGLWidget and QQuickWidget, will use the same format, eliminating
the possibility of failing due to trying to share between incompatible contexts.
Furthermore, since such a functionality is anyway mandatory for QQuickWindow
(due to the possibility of creating windows from QML code), extending it to
QSurfaceFormat and QOpenGLContext/QWindow is the next logical step.
Change-Id: Ie94486adc489d17fecfcebb7050fecedffd2688b
Reviewed-by: Gunnar Sletta <gunnar.sletta@jollamobile.com>
When a dialog was parented on a native child widget,
its window handle was used as a transient parent.
This confused QPlatformWindow::initialGeometry() among
other things. Use top level window as is in Qt 4.
Task-number: QTBUG-40195
Change-Id: Ic82adc276175f92adde825fb2551274351e41f30
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
This causes a closeEvent to be sent for all calls to close.
As a side effect destroy now handles more of the state in
QGuiApplication.
[ChangeLog][QtGui][QWindow] QWindow::close() sends a QCloseEvent
which must be accepted before destroy() will be called. destroy()
is the function to close the window without confirmation.
Task-number: QTBUG-40093
Change-Id: I1ce09da4940fc29fae8decf40548a42e3bec6eca
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Change the semantics of QWindowPrivate::screen to contain the screen of
top level window only. Child windows always return the screen of their
toplevel window by recursing up.
The QPA plugins then no longer need to report screen changes for child
windows.
Change setScreen() accordingly, bail out for child windows, and
emit screenChanged() recursively.
Also add a check to setParent() preventing screen changes.
Task-number: QTBUG-36659
Change-Id: I19c8e12217cba1513e947a027f2492abc7b98816
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
The event handler would ignore the close if the window was hidden
while the close() function would not. In addition, the close()
function would force removal of focus etc while the event handler
did not. Make it consistent by calling close() from the event
handler.
Change-Id: Ia05b08299f218620fb40a8cad5d3771158c4701e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
The desktop doesn't belong to this application, we shouldn't be setting
it (assuming it is even possible). On X, for example, it's possible to
set the name and you end up with the root window having _NET_WM_NAME
pointing to the last application that created a QDesktopWidget.
Change-Id: Ib62d0a4d56a4d2a74afc6b33fa607867343e7aba
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
If the override cursor was set before
QtQuick2ApplicationViewer was shown then the cursor
was the default cursor and not the override cursor.
The new cursor was applied only if the window was
visible and the cursor has been set. Now the cursor
is applied also if override cursor is set.
Change-Id: I88618c719e43b2802e209bef440461c532d19f48
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
[ChangeLog][QtGui][QGuiApplication] Add support for -icon command line
argument on X11, add -qwindowicon on all platforms.
Change-Id: Iacc602466699bf634d8b34aab7ed73c83fd9844f
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
When a window is shown, libscreen will give it keyboard focus.
Requesting the activation right after the window is created (and
before libscreen activated the window) causes problems on some devices
e.g. Q10.
Change-Id: I29f7a38990ea4259a8b0c6624f70e31d7291af00
Reviewed-by: Sergio Ahumada <sahumada@blackberry.com>
Asserting is only relevant for debug builds, and there were a couple
of other places that a segfault would typically occur before the assert
had a chance.
Change-Id: I1abc82eb3ecfa91050117fab1525f4cbd82ff486
Task-number: QTBUG-37876
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Laszlo Agocs <laszlo.agocs@digia.com>
Similary to QWidget's windowTitleChanged, QWindow should also have a
windowTitleChanges signal that's emitted when the title changed and declared
as notify signal for the title property, so that QML bindings can be written
against it.
Change-Id: I6f107c6f0b43d6a959bc2ef96492e1f3e4c28bfe
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
[ChangeLog][QtGui][QWindow]QWindow::icon() now defaults to the application
icon, which can be set with QGuiApplication::setWindowIcon().
Change-Id: Id1974e5cda81775e515c14b294f67fb99351c6c9
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
-title disappeared between Qt4 and Qt5, due to all the refactorings around QPA.
Making the caption of the mainwindow configurable allows custom setups
for specific users or use cases.
[ChangeLog][QtGui][QGuiApplication] Restore support for -title command line
argument on X11, add -qwindowtitle on all platforms.
Change-Id: I73e6bf21248f3419178eba583b257172a175e74e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Makes it easier to add code in the future too.
No-op change.
Change-Id: I228c36813ccf8ee95ed4b6cbbc20af3178d1b84a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Might be useful to expose to QWindow in 5.3, but for now it's private
so it can be used by platform plugins.
Change-Id: Iad96d7e249a7b85695668f8d7e8918164ec67442
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
The ShowIsMaximized and ShowIsFullscreen style hints were not granular
enough to build a default behavior from that would be correct for all
platforms. The recent Android patch that excluded dialogs from being
shown maximized (Ia249e93dbbea1) has now been moved into a platform
override in the Android integration plugin, leaving other platforms
to the default behavior of using the style-hints. We still special
case popup-windows though, as that behavior has been there for a
while.
Task-number: QTBUG-34969
Change-Id: Id36346d71bfc46171383ffe334592ca0b94e456f
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
This code path can and will be hit during app startup,
and can result in low-resolution images being used
on high-dpi systems.
Use qApp->devicePixelRatio() instead, which is more
likely to be correct.
Change-Id: Ic881cfedd8e962037d2d4af4a1242f590d56c194
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@digia.com>
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
The default is now ShowMaximized which behaves as it did before,
i.e. each window will fill the screen but the status bar will be
visible. Calling showFullScreen() explicitly will now hide the
status bar to maximize the amount of screen real estate occupied
by the application.
Task-number: QTBUG-33135
Change-Id: If0d0a2ab72f8026e76818290e2b953dbc0dec156
Reviewed-by: BogDan Vatra <bogdan@kde.org>
On mobile platforms, a line edit should only have keyboard focus
when the virtual keyboard is open. As it stands, the only way to
clear focus when the user hides the keyboard, is to deactivate the
whole window. This is a bit too much, since Qt still expects the
window in front to be active/focused. What we need is a way to
remove focus from the current focus object without disturbing
the state of the window.
QWindow has a virtual function 'focusObject' from before. We now
add a virtual function 'clearFocusObject' to QWindowPrivate
that can be overridden by QWidgetWindowPrivate and
QQuickWindowPrivate. That way we can remove focus from current
focus object when the virtual keyboard is closed from the
platform plugins.
Change-Id: Ica4ec76f8a69cd6107236a8000ff8bd742e988b5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@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 platform window creation is policy is such that native resources are
created only when necessary. Since QWindow already tracks
contentOrientation, there is no reason to implicitly create a platform
window when a content orientation change is reported. This makes
content orientation follow the same convention used by windowState.
Change-Id: Ic9920360791e3e5b2abbc36df631a3e53931835b
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
It handles window movement events, not mouse move events.
Change-Id: Ibc8fd0272756fcf87dfac210addbf2f87cfb39d5
Reviewed-by: aavit <eirik.aavitsland@digia.com>
In "very basic platform plugins", the platform window ID can be null,
which conflicts with QWidget's special treatment of 0 as a parented widget.
Such is the case with EGLFS, which can return a null native window handle
for winId on some EGL implementations.
Move the assertion winId!=0 into the widget framework, as this assert is
not relevant for non-widget applications. A large proportion of basic
platform plugin users will see relief from this unnecessary assertion.
Change-Id: I25c9d96550cd747c77c9516d773e9cdebf7440ab
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
so that part of Id03ae17270832a7b5915e4324a508e591c0b6d98 which added
the Q_REVISION(1)'s and \since docs was a mistake.
Change-Id: I159b68491bd7dc55657d8c978bff527094ef4547
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@digia.com>
Reviewed-by: Alan Alpert <aalpert@blackberry.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>
It's possible to override event() to receive the QCloseEvent and
do event->ignore() to prevent the window from closing.
Task-number: QTBUG-31019
Change-Id: I9abed47fca02a002b78727f98d678a824854adfc
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Add QWindow::alert() and QPlatformWindow::setAlertState().
Add logic to clear alertion state when the window becomes
active. The platform plugins then only need to implement a setter
and a cheap getter and need not handle activation.
Prototypically implement X11 and Windows.
Task-number: QTBUG-30416
Change-Id: Ia70c4722d812462a21f4034b7d52735c9f2bc49c
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Fix the documented function signature to match the declared one.
Task-number: QTBUG-30398
Change-Id: I0d4894e2597f70e29a3edd4ceda91a4dddb9941e
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Needed as a consequence of I4f5e37480eef5d105e45ffd60362a57f13ec55f5
Otherwise a Window in QML doesn't get notified to update its layout
after being mapped the first time, on Linux.
Change-Id: I8b1291e16b11eb93ab045ac5c5ed6b478391cb21
Reviewed-by: Jan Arve Sæther <jan-arve.saether@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>
If the window or widget is a popup, ignore the hint. The
intention of the flag should be to show main windows etc in
fullscreen, and not all kinds of popups and tooltips. The user can always
call showFullscreen explicit when necessary.
This is a backport of 48c73540ad.
We need it in stable to fix menus on BlackBerry platform, they're
appearing fullscreen.
Task-number: QTBUG-29969
Change-Id: Id0d6cfc194916aa7f993cde54b5a0002f60399e1
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Default-constructed geometry does not mean put the window at 0,0,
and it does not mean center the window on the screen: it means
let the window manager position the window. If the window is
explicitly positioned at 0,0 though, that is a higher priority
than the transient hint; without this change, the transientFor property
had no effect. On X11, transient means use center "gravity" to
make the transient window exactly centered. But the user can still
override the geometry of a transient window, as with any window.
On OSX and Windows, neither transient window functionality nor smart
initial positioning are provided, so a window with no position set
will be centered on the screen, and a transient window will be put
at the center of its transientParent.
Change-Id: I4f5e37480eef5d105e45ffd60362a57f13ec55f5
Task-number: QTBUG-26903
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
This finally makes it possible to make windows fullscreen etc from
QML by doing "visibility: Window.FullScreen". I don't see any reason
from not having the API at the QWindow-level instead of at the
QQuickWindow-level since this way it can benefit other use cases too.
Change-Id: If27344306eb563bc2ccd83296a46b1f2862e2db1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
If the window or widget is a popup, ignore the hint. The
intention of the flag should be to show main windows etc in
fullscreen, and not all kinds of popups and tooltips. The user can always
call showFullscreen explicit when necessary.
Change-Id: Ie150b6c6d7ca6c9344a9097544a7edbc4bd10df2
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Currently, there is no concept of not having a cursor set on
a Window. Qt::ArrowCursor is always set instead. This causes
bugs when native child widgets are involved, for example setting
a cursor on the native widget's parent no longer works since
the child's Qt::ArrowCursor applies.
Introduce QWindowPrivate::hasCursor tracking whether a cursor
has been explicitly set and clear in QWindow::unsetCursor().
Handle 0 in QPlatformCursor::changeCursor() to mean
"unsetCursor()":
- Windows: Introduce default constructor for QWindowsWindowCursor
meaning "0". Search for applicable parent cursor in applyCursor.
- XCB: No big changes required, set XCB_CURSOR_NONE for no cursor.
- Other platforms: Assume Qt::ArrowCursor when cursor = 0 is
passed for now.
Task-number: QTBUG-28879
Change-Id: Id82722592f3cd5fe577a5b64dcc600c85cfea484
Reviewed-by: Jonathan Liu <net147@gmail.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
We should only emit these when the corresponding property value changes.
Since these are changed asynchronously in the case of a platform window,
we should not emit them in the setter, as they are already properly
emitted in QGuiApplicationPrivate::processGeometryChangeEvent().
Change-Id: I5ac00601ddb4e7a8ff02376e5f5135d427913119
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Pass opacity from the QWidget to QWindow and to the platform
windows.
Task-number: QTBUG-28477
Change-Id: If5a85d9183bd1ca33dac2052936ecd1e6c0b5f6c
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
If we don't do this, we can have binary compatibility issues later.
For example https://codereview.qt-project.org/#change,41700 will change
the behavior of setWidth and setHeight to call setSize instead of
setGeometry, because we don't want changing the height to also set
the position of a window; if x and y are left uninitialized it needs
to remember that fact. But if setWidth is left as an inline method,
calling setGeometry, then an application which was built with 5.0
would behave differently than an application built with 5.1, even if
Qt is upgraded after the application was built. To generalize,
setters should never be inlined.
Change-Id: I1ec42cb61a45fe541b3f3bb99d1b1ca24ad2a517
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
There are no proper implementations of this API, and as it stands it
only acts to confuse anyone who stumbles across it. It will be better to
revisit the full cross platform orientation API story for 5.1.
Change-Id: Iff7054a32c6e5e4ad0cc0493a5e4ecc35a6ec4f3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Bring Qt 5 on par with Qt 4, prepare for more comprehensive
support later on.
Introduce device independent pixels (dips), device pixels,
and devicePixelRatio. Add high-dpi support to QPainter,
QGLWidget, the cocoa platform plugin, mac and fusion styles.
Dips are similar to CSS pixels, Apple points and
Android density-independent pixels. Device pixels
are pixels in the backing store/physical pixels on screen.
devicePixelRatio is the ratio between them, which is
1.0 on standard displays and 2.0 on "retina" displays.
New API:
QImage::devicePixelRatio() and setDevicePixelRatio()
QPixmap::devicePixelRatio() and setDevicePixelRatio()
QWindow::devicePixelRatio()
QScreen::devicePixelRatio()
QGuiApplicaiton::devicePixelRatio()
Change-Id: If98c3ca9bfdf0e1bdbcf7574cd5b912c9ff63856
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
QWindow::screenDestroyed triggers an move of the window to the primary
screen. This causes the screen to be destroyed and shown again on the
new QScreen.
The issue is that QWindow::destroy() hides the window but create()
doesn't set it visible, and this ultimately causes any QWindow to be
automatically hidden when their QScreen is destroyed.
As stated in the comment, it could be the intended behavior that
windows aren't shown automatically on a remaining screen like when
using two screens not logically part of the same desktop. Once the
platform plugins have access to an API allowing them to adjust the
screens of their QWindow, this patch shouldn't be needed anymore.
Change-Id: I7628377c969f79f9eebb3deabaf0470542d68a9c
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
As 672e7c875e did changing pos() to
position() and setPos() to setPosition().
Luckily there's not much code that uses these.
Change-Id: I1e1982f00412a22bd376e667a5e8c30b6149f9b5
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
The missing break causes state change event handling to fall through
to tablet event handling, which is clearly wrong.
Change-Id: If19d7b3f794b3614961b9e79952331b0ede1fba1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Abbreviated properties are to be avoided. But all 3 of these
properties are redundant from the QML perspective; and because QRect,
QPoint and QSize are (wisely) not QObjects, it's not possible to bind
to _their_ properties, which make these QWindow properties less useful
than users might assume that they are.
Change-Id: I19c00b54b1d2712f9418e8bcf56e35a8008b89ef
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
windowTitle, windowModality, windowIcon and so on are named that way
to be similar to the ones in QWidget. However QQuickWindow inherits
all of the declared properties, and we would like to have shorter
property names in QML. If you are working with a Window then it's
obvious the title property is the window title. Unfortunately,
there must be patches in many other modules which depend on this one.
In order to avoid the need to merge them all at the same time,
there is also patch https://codereview.qt-project.org/#change,39001
which temporarily adds backwards-compatible accessors, which can be
removed after the other modules are able to build without them.
We should not rename windowState to state, because in QML, state
usually drives the state machine for animation transitions etc.
(although QWindow is not an Item, a user might get confused about it).
Related patches are
https://codereview.qt-project.org/#change,39001https://codereview.qt-project.org/#change,37764https://codereview.qt-project.org/#change,37765https://codereview.qt-project.org/#change,37766https://codereview.qt-project.org/#change,37762
Change-Id: Ie4424ec15fbdef6b29b137f90a2ae33f173edd21
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
These are useful when QWindow is exposed to QML.
Change-Id: I7ec49ef365183e2c784605889e8ea22c2ef34781
Reviewed-by: Jens Bache-Wiig <jens.bache-wiig@digia.com>
If a modal dialog was shown as a response to button click, the button
retained its hover highlight, because it didn't get leave event.
Fixed by tracking the most recently entered window and sending a leave
to it when modal dialog is shown that blocks it.
Also modified tst_QGuiApplication::modalWindow() autotest to check
for enters and leaves.
Task-number: QTBUG-27644
Change-Id: I387647e18a762a39d523e3df31221b9583a39f9d
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
The current implementation requests the platform window to set
the window state if it can, and return the actual window state
back.
The problem with this approach is that the platform window is created
as late as possible, so a call to QWindow::setWindowState would in
many (most?) cases never be forwarded to the platform window (instead,
the platform window is responsible to check the current window state
upon creation). As such, the window state might be left unsynched with
the platform window.
This patch suggests removing the return value from
QPlatformWindow::setWindowState. This will at least be consistent, so
that setting/getting state would produce the same result independent of
delayed window creation. If needed, we can later add new API to
QPlatformIntegration or QPlatformWindow for querying supported/actual
window state.
Change-Id: Ie43f56169656854a765ce88b47a808f8f3d51bb4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
If custom cursor was set before the window was created, it didn't
actually get set, and in some cases even caused a crash.
Fixed by making sure the cursor is correct when showing widget/window.
Task-number: QTBUG-27535
Change-Id: I3bc946a9c406c96af5b86869a3a54893f8980aba
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Gatis Paeglis <gatis.paeglis@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
The current implementation requests the platform window to set
as many of the flags it can, and return the same flags with the
unsupported flags removed.
The problem with this approach is that the platform window is created
as late as possible, so a call to QWindow::setWindowFlags would in
many (most?) cases never be forwarded to the platform window (instead,
the platform window is responsible to check the current window flags
upon creation). As such, the filtering would never be done.
Looking at the current set of plugins, most of them also seems to
ignore this protocol, returning the flags unfiltered.
This patch suggests removing the return value from
QPlatformWindow::setWindowFlags. This will at least be consistent, so
that setting/getting flags would produce the same result independent of
delayed window creation. If needed, we can later add new API to
QPlatformIntegration or QPlatformWindow for querying supported window
flags.
Change-Id: I9c759b5f9fab5ebed764a982f77fe19881118875
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
Even child windows need to hook into the screen destroyed signal to
avoid having a dangling screen pointer.
Change-Id: I7b613356c333be6e9dfdf5db45f70a521a9b8fe2
Reviewed-by: Shawn Rutledge <shawn.rutledge@digia.com>
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
QWindow::setWindowFilePath sets the file path of the document
that is currently represented by the window.
The window system might display it in the window's title bar
along with an icon matching the file type.
Task-number: QTBUG-27299
Change-Id: I8f620d1262fc0b4cd16884198b16853b73ce3b1f
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@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>
QWidget's mapToGlobal() and mapFromGlobal() functions assumed that
if the widget reports it's a window or if it has no parent widget, it
must be a top level window whose coordinates are in global coordinates.
This is not true for child QWindows or embedded native windows
(QAxWidgets).
Changed the logic for mapping coordinates to use equivalent methods
from QWindow if widget has a window handle, and changed QWindow's
methods to map coordinates using native methods if window is embedded.
Also fixed newly failing accessibility autotest. The geometry related
failures there popped up because now the position of the rect returned
by accessible interface is actually correct while widget geometry still
reports position 0,0 before widget has shown up.
Task-number: QTBUG-26436
Change-Id: I658fafd0ce01eb1604ba255efeeba3073ca0189f
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
This is the result of running util/normalize --modify
from Qt 4.7 with manual review.
Change-Id: I36e54222b27f1e71eb7d89cdfc595177c8d2bdb3
Reviewed-by: Laszlo Papp <lpapp@kde.org>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Primary goal, make the front page of the Qt GUI module a bit more
clarifying and avoid downstream references inside the Qt GUI docs.
Change-Id: Icbcfbb64b93963add889bf83711daa9575885c02
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Mouse / enter / leave / key events etc are all blocked when a window has
the blockedByModalWindow flag set. The problem appears if a QWindow is
created and only later directly or indirectly parented to a modal window
that's currently showing. Since the decision on whether a window should
be blocked or not is based on its parent / transient parent chain, we
need to reevaluate the blocked status each time the parent or transient
parent of a window changes.
Task-number: QTBUG-26112
Change-Id: Ida6b118b556fe26d17fa86335a0fe7baddc7eaf8
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
We need to let the QGuiApplication determine whether quitting is appropriate
based on whether there are visible top level QWindows after the last top-level
QWidget was closed.
This solves the issue raised here: http://thread.gmane.org/gmane.comp.lib.qt.user/1880
The transientParent is the QWindow equivalent of parentWidget on QWidget, so the test
in QGuiApplication::shouldQuit is similar to the one in QApplication::shouldQuit.
Change-Id: I500eff8d5887f24415180134b3a4be3c630a896f
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Should be sufficient to allow implementing the actual functionality in
xcb/cocoa/windows to match the Qt 4 level of tablet event support.
Task-number: QTBUG-25864
Change-Id: Iebcca256dfba841d8976b58fda1b76026d3133a3
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
QWindow::setSurfaceType and QWindow::setFormat do not re-create
the QPlatformWindow. Attempt to document this behavior and point
to the documentation of destroy() and create().
Change-Id: Idf7eb343d4918a45b5a701effe3263145a33790a
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
Since QIcon has been moved back to QtGui, QWindow::setWindowIcon can
use it. That way, the api is exactly the same as in QWidgets and one
can deal properly with multi-sized icon.
I added a getter so the api is consistent with QWidget
(Maybe there should be properties for windowIcon and windowTitle)
Change-Id: I2f463dbe39673f41a3201ef8fed27b3fcac2125f
Reviewed-by: Girish Ramakrishnan <girish.1.ramakrishnan@nokia.com>
The main reasons for doing this are:
1. _qpa.h end up in the master QtGui include file. QtGui is meant for
userland applications. qpa code is neither binary nor source compatible.
Inadvertant use of QPA api makes the user code binary-incompatible.
2. syncqt creates forwarding headers for non-private header files. This
gives people the impression that this is public API.
As discussed on the mailing list, even though QPA api is internal and subject
to change, it needs to treated differently from private headers since they
will be used by in-qtbase and out-of-qtbase plugins.
This commit does the following:
1. The _qpa in QPA header files is dropped.
2. syncqt now treats any file with qplatform prefix as a special file and
moves it to qpa/ directory. The recommended way of using QPA API in plugins
is: #include <qpa/qplatformfoo.h>. This allows the user include QPA API
from multiple modules (for example, qplatformfoo might be in QtPrintSupport)
3. The user needs to explicitly add QT += <module>-private to get access to
the qpa api.
4. Creates compat headers for the olden style qplatformfoo_qpa.h and QPlatformFoo
includes.
This commit does not change the cpp filenames. This requires a more careful
merging of existing non qpa cpp files and existing cpp files on a case by
case basis. This can be done at anytime.
The following files are not renamed as part of this changed but will be fixed
as part of a future change:
src/gui/kernel/qgenericpluginfactory_qpa.h
src/gui/kernel/qgenericplugin_qpa.h
src/gui/kernel/qwindowsysteminterface_qpa.h
files were renamed using
for x in `find . -name "qplatform*_qpa.h"`; do git mv $x "${x/_qpa.h/.h}"; done
for x in `find . -name "qplatform*_qpa_p.h"`; do git mv $x "${x/_qpa_p.h/_p.h}"; done
includes were renamed using script
for file in `find . -name "*.h" -or -name "*.cpp" -or -name "*.mm"`; do
sed -i -e 's,.*#.*include.*<\(Qt.*/\)\?\(QPlatform.*\)>,#include <qpa/\L\2.h>,g' \
-e 's,.*#.*include.*"\(Qt.*/\)\?\(QPlatform.*\)",#include <qpa/\L\2.h>,g' \
-e 's,.*#.*include.* "\(qplatform.*\)_qpa.h",#include <qpa/\L\1.h>,g' \
-e 's,.*#.*include.*"\(qplatform.*\)_qpa_p.h",#include <qpa/\L\1_p.h>,g' \
-e 's,.*#.*include.*<\(Qt.*/\|Qt.*/private/\|private/\)\?\(qplatform.*\)_qpa\(.*\)>,#include <qpa/\2\3>,g' \
-e 's,.*#.*include.*"\(Qt.*/\|Qt.*/private/\|private/\)\?\(qplatform.*\)_qpa\(.*\)",#include <qpa/\2\3>,g' \
$file
done
Change-Id: I04a350314a45746e3911f54b3b21ad03315afb67
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Sean Harmer <sean.harmer@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
The correct api is QWindow::isVisible(). Removing the api
is safe since QWindow is not even released yet.
Only qtdeclarative needed to be fixed with
71c8fe296fe5aa7e79033dd8f5b539852d4276e0.
Change-Id: Ie571ed4802fe89132419e402acdb854446f4578f
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
fa0407bdb5 moved all QSurface code to
a separate except the destructor.
Change-Id: I2bf426a0b70cbffafae7aca8dd5550192f762aeb
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
QWindow already has windowModality() and setWindowModality() as part of
its API from commit 516f4e283b. Platform
plugins can use this already to setup modality hints on windows that
they create, but it's not enough to implement modality fully.
QGuiApplication gets a modalWindow() static method, which is similar to
QApplication::activeModalWidget() in that it returns the last modal
window to be shown.
The modal window "stack" moves from QApplicationPrivate to
QGuiApplicationPrivate. The enterModal*() and leaveModal*() functions in
QApplicationPrivate are removed and replaced by
QGuiApplicationPrivate::showModalWindow() and hideModalWindow(), which
are called by QWindow::setVisible() just before calling
QPlatformWindow::setVisible().
The virtual QGuiApplicationPrivate::isWindowBlocked() will tell us if a
window is blocked by a modal window (and tell which modal window for any
interested callers). The default implementation works on the QWindow
level. QApplicationPrivate reimplements isWindowBlocked() and adds popup
and WA_GroupLeader support.
QGuiApplication uses the state set from isWindowBlocked() to block
user-input events: mouse press, mouse move, mouse release, wheel, key
presses, key releases, enter/leave events, close events, and touch
begin, update, and end events.
Note also that the modality helper functions in QtWidgets and
QApplicationPrivate are left in place and working as they always have.
The behavior of QWidget in the presence of modal windows/dialogs should
not change.
Change-Id: I2c89e6026d40160387787a6e009ae1fdc12dfd69
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
This also adds the QWindow::windowModalityChanged() signal.
Change-Id: I6e3bc3155d72811d173857c39d36dcb264928334
Reviewed-by: Alan Alpert <alan.alpert@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Both QWindow and QWidgetWindow should update with the
active state signal.
Change-Id: I0219f803aa0fb109765f0faa0aedb120c2a439f0
Reviewed-by: Jan-Arve Sæther <jan-arve.saether@nokia.com>
Since change 2e4d8f67a8 the need for Map and Unmap events has
gone away, as now the Expose event is used to notify the application
about when it can start rendering.
The Map and Unmap events weren't really used except by QWidget to set
the WA_Mapped flag, which we now set based on the expose / unexpose.
Also guarantee that a Resize event is always sent before the first
Expose, by re-introducing an asynchronous expose event handler. Since
an expose is required before rendering to a QWindow, show a warning if
QOpenGLContext::swapBuffers() or QBackingStore::flush() if called on a
window that has not received its first expose.
Change-Id: Ia6b609aa275d5b463b5011a96f2fd9bbe52e9bc4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
\since 5.0 has been add to the class section, so member functions and
properties donot need this any more.
see SHA: 5728c8a8e7
Change-Id: I4e67461373dda99ee1fbfdeb6477fde1dcfec116
Reviewed-by: Casper van Donderen <casper.vandonderen@nokia.com>
In QTBUG-24807 there is a test case that shows a case when a segmentation
fault happens inside isAncestorOf. When the whole application loses the
focus, e.g. when it is minimized or other application receives the focus,
QGuiApplication::focusWindow() returns a null pointer, so we need to
do a check before proceed inside of isActive.
Task-number: QTBUG-24807
Change-Id: I732c92bb9f236804ede5e89592f6e6609a4711b9
Reviewed-by: Jesus Sanchez-Palencia <jesus.palencia@openbossa.org>
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Since we're not yet confident if they serve their purpose well enough,
we have decided to make them internal so that we are free to tune them
later
Change-Id: Id79d154e0537aca07303afea5d057cfcb0773384
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
This is motivated by visiting a customer that re-implemented the
::winId method and returned WId(0) that resulted in a crash. Currently
there is only a comment inside the implementation of the ::winId
default implementation. Add a note to the API documentation, add
a Q_ASSERT to check if our assumption holds true.
Change-Id: I8607a4efc4f561f7849c976cd2454f6fbcb20eaa
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
The visible property along with show/hideEvent tracks the
windows visibility from the application perspective and is
really a request. The exposeEvent() along with the isExposed()
accessor is used to notify the application of the actual
state of the window in the windowing system.
Change-Id: I7f5b7ed74a168e34aaa21ce0ae9042ddfb0bf6d8
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
Change-Id: I14706abb8441c153f738563cb1a46205fdb2dae6
QWindow::visible() did not follow the API guidelines.
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
Instead of refcounting QWindow visibility, we ask the Application
subclass whether quitting is appropriate.
Task-Id: QTBUG-24120
Change-Id: Idd19cc1a3e5742fddded89c7638aaaa5e47c568d
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
When closing a window, destroy() ensures a setVisible(false) call only
for the window itself, not for other windows parented to it. With the
new quit lock ref feature this breaks code that creates a fake root
window parented to the main, visible window. (for example the
xcomposite backends of qtwayland do this)
Such apps do not anymore exit after closing their window because the
children do not receive a deref due to setVisible not getting called.
(At that point. It would get called after exiting the event loop but
that never happens due to the refcounting)
Change-Id: I124737c80ad59600ddc79261100f3904af0f410d
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
A feature of a ref-counted quit (managed by a quit-lock class)
is added to both QEventLoop and QCoreApplication.
This allows, for example, an event loop to quit() when there is
no more work for it to do.
quitOnLastWindowClosed is implemented in terms of the refcount in
QCoreApplication so that jobs can be completed before the
application quits.
Change-Id: I14c8f4e7ee12bbf81a6e5849290d4c8ff37fa110
Reviewed-by: David Faure <faure@kde.org>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
* Deprecated QInputPanel::inputWindow() which is already
just returning QGuiApplication::activeWindow()
* Deprecated QInputPanel::inputItem() and introduced
QGuiApplication::focusObject(). Input methods can check
input method support by Qt::ImEnabled query.
Change-Id: I70a9c1c3f79aadb75c839d0489a9428f7a221df5
Reviewed-by: Joona Petrell <joona.t.petrell@nokia.com>
Implement the public slot QWindow::close() and add the correspondent test.
Change-Id: If3f07cce3b26640f06fc52d0e4dca875d9894b3d
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>
To match the previous QWindow::orientation() property which can be
useful to access from QML. Also, removed the automatic translation of
Qt::PrimaryOrientation to QScreen::primaryOrientation() on the QWindow
level, as it leads to a lot of complexity regarding the
QWindow::contentOrientationChanged() signal, and makes it hard to
distinguish between the case where the window's orientation follows
that of the screen, and the case where the orientation just happens to
be set to that of the screen.
Change-Id: I6950d1337b7f929815eff1328181855090d8066b
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Previously we only had QWindow::setOrientation() which was a hint about
the orientation the window's contents were rendered in.
However, it's necessary to separate between the orientation
corresponding to the window buffer layout and orientation of the
contents. A game for example might typically want to use a landscape
buffer even on a portrait device. Thus, we replace
QWindow::orientation() with QWindow::reportContentOrientationChange() and
QWindow::requestWindowOrientation().
Change-Id: I1f07362192daf36c45519cb05b43ac352f1945b5
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This takes out the dependency to the header files
of OpenGl. The ifdef QT_NO_OPENGL in the opengl headers
are needed, as qmake adds depends in the makefiles
for all GUI headers.
Task-number: QTBUG-23207
Change-Id: If31448ee35fd8c39194c7cb7d62273fbc6def883
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Reviewed-by: Gunnar Sletta <gunnar.sletta@nokia.com>
It was 'windw' instead of 'window'
Change-Id: I3a7b361a22e4ea09ee1fb3d9b551c1a88d401ff1
Reviewed-by: Jonas Gastal <jgastal@profusion.mobi>
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
The current way we do it of having the platform or touch plugin send
both mouse and touch events is not ideal. There's no good way to write
an application that works sanely both on a touch-only device and on a
desktop except by restricting yourself to only handling mouse events. If
you try to handle touch events you don't get any events at all on
desktop, and if you try to handle both, you end up getting duplicate
events on touch devices.
Instead, we should get rid of the code in the plugins that automatically
sends mouse events translated from touch events. This change enables
that by making the behaviour fully configurable in QtGui.
Two new application attributes are added to explicitly say whether
unhandled touch events should be sent as synthesized mouse events and
vice versa, and no duplicates are automatically sent as the current
situation. Synthesized mouse events are enabled by default.
We also get rid of the QTouchEvent::TouchPoint::Primary flag, which
was only used to signal that the windowing system automatically
generated mouse events for that touch point. Now we only generate mouse
events from the first touch point in the list.
Change-Id: I8e20f3480407ca8c31b42de0a4d2b319e1346b65
Reviewed-by: Laszlo Agocs <laszlo.p.agocs@nokia.com>
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@nokia.com>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@nokia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Denis Dzyubenko <denis.dzyubenko@nokia.com>
Traditionally it's been hard to write a Qt app that behaves sanely
across embedded and desktop platforms, i.e. defaults to fullscreen on
embedded and non-fullscreen on desktop. For Qt 5 we can fix this by
making the behaviour of the default QWindow::show() be customizable by
the platform plugin.
If the application developer wants to override this behaviour he can
still use the explicit showFullScreen(), showNormal() etc functions.
Change-Id: I26a907b404058e345d841c818daefbb57a26d3fd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
Reviewed-by: Jørgen Lind <jorgen.lind@nokia.com>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@nokia.com>
Unlike keyPressEvent(), mousePressEvent(), etc. the touch events had
no equivalent so one had to fall back to reimplementing event() or
using an event filter. This is now corrected by introducing
touchEvent(). Touch events are finally becoming a first-class citizen
in Qt 5.
Change-Id: Ia2044030154fd5b1b5384f08a3cb1749b798435f
Reviewed-by: Samuel Rødal <samuel.rodal@nokia.com>