| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch, we would only rotate if no autoRotationMask was set.
This was a temporary way to lock orientation from code until a better
API for this was in place.
But this causes problems for applications that both wants to auto rotate
but at the same time sets a mask to get QScreen::orientation
updates. So remove this heuristic before application code starts to
depend on it.
Change-Id: Idb54abd471b33afd866322738f4860c57bc9dcf7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We create our QIOSViewController in didFinishLaunchingWithOptions,
and schedule a timer to run the user's main. If the device is
placed in landscape orientation at startup, we will receive a
willRotateToInterfaceOrientation message before the timer is
triggered to run the user's main, which means we do not yet
have a QApplication.
To fix this crash we exit early, but we might have to store the
new orientation for later, and make sure the initial QScreen is
then created with the correct orientation.
Change-Id: I0cc02f0d36b992d190736e98858dc7d002d595b7
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
| |
|
|
|
|
|
|
|
|
| |
The former represents the physical device orientation, the latter the
UI orientation. We need to explicitly cast between them, as they are
different enums, but with compatible values for the subset we use.
Change-Id: I2926068802f35680cb6de5ced6dcf286014fdb2e
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The qobject_cast to QGuiAppplication will always
fail at startup since QGuiApplication is not ready
yet.
Return YES in that case. Allowed orientations can then
be controlled by setting "Supported Interface Orientations"
in Xcode or the Info.plist file.
Change-Id: Ifd86bbcedabc716e63563bbb7cb0c1c6833fd6c7
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
| |
Change-Id: Ie9131c3dfe16045805b37bf8af9381f4f9929da6
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
| |
We need to update primary orientation when the rotation starts, and
not when it ends, so that we are in sync with the resize that happens
to the backingstore upon layoutSubviews.
Change-Id: I466a2d135e6c15550c6207c9659871629d748b73
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
| |
Some functions are needed across several files and classes. Lets
place them in a common file for all to use.
Change-Id: I5f9b578f948d66d10e57a835b80b5c493e07fb4c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Clean up a bit. The orientation conversion functions belongs to
QIOSScreen more than QIOSOrientationListener. And rename them in
the same go to follow toQRect/fromQRect standard.
The orientation listener itself is tightly coupled to QIOSScreen, and
does not make much sense on its own, so move it into QIOSScreen to
follow the same patteren already implemented for QIOSInputContext.
Change-Id: I8b6b4d08a42349b4232749d59d46748297083536
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
Qt expects the screen to change geometry when the "desktop" rotates.
On iOS, we interpret this as when the root view controller changes
orientation, since after all, this is the surface we place QWindows
on top of.
Change-Id: Ia00e68c8f9f0a65aefcc60518ee544fb260d4595
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
| |
This is an intermediate heuristic until we have a proper API in Qt to
deal with auto-rotation and orientation locking.
Change-Id: I433992fa1c18d1670987f79e405a4501b6e5d365
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
| |
The API is scheduled to be removed in qtbase in time for Qt 5.0.
Change-Id: Ie34d6cb79fcd81b0ce02892529e3e7184ddfa096
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The application is normally supposed to rotate the content on its
own, but can call requestWindowOrientation to ask the window
manager to do it instead. This way of integrating orientation with
the OS is fragile, because:
1. In some cases, you cannot stop the OS from rotating at all
(tablets).
2. It would be more safe to inform the window manager up-front
which orientations it could rotate into, rather that relying
on a function you call call to force this later on.
3. When the QML application starts, its a bit late to inform
the platform plugin that it supports e.g landscape. If the
OS is in landscape already, the plugin must still assume that
the app operates in portrait (doing rotating on its own) until
requestWindowOrientation is called. This might cause the app
to first start up in portrait, just to rotate into landscape.
On iOS, it seems like we can handle the first two cases. The third
need some more investigation. We should anyway investigate if we
need some adjustment to the Qt API.
Change-Id: I50638b78d469ab70820a787de86a2f1981470786
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
|
|
We need our own viewcontroller to better control which
orientations iOS can enter, and also ito be able to
stop auto-rotation.
We stop auto-rotation to happend by default, since this is
how Qt wants it (it is seen as the responsibility of the
application).
Change-Id: Id07a96e355396752fffd28984af528aeb0b7c3e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
