[Development] Heads up: Late API removal from QWindow

Hausmann Simon Simon.Hausmann at digia.com
Wed Dec 5 18:23:51 CET 2012


We do have evidence that the client side orientation model works, makes sense and is in use.
Leaving out the API for the server side model sounds like a good idea until we have confidence and evidence that it works.


From: development-bounces+simon.hausmann=digia.com at qt-project.org [development-bounces+simon.hausmann=digia.com at qt-project.org] on behalf of Samuel Rødal [samuel.rodal at digia.com]
Sent: Wednesday, December 05, 2012 6:12 PM
To: development at qt-project.org
Subject: [Development] Heads up: Late API removal from QWindow


with the iOS platform port coming along we've done some discussions
regarding the whole orientation story in Qt. There are two main ways of
doing orientations in Qt at the moment, depending on the platform. On
desktop platforms, orientation changes typically happen when you rotate
your screen to be in vertical orientation and change the corresponding
setting in the screen control panel. This results in
QScreen::geometry(), QScreen::primaryOrientation() etc changing, and if
a QWindow is fullscreen or maximized it will also be automatically resized.

On mobile / tablet, the application can ask for notifications about
orientations by setting the orientationUpdateMask in QScreen.
QScreen::orientationChanged() will then fire based on how the device is
held. The application can react to this by manually doing a rotation on
how it draws its window contents, possibly with a transition animation
(QML makes that kind of stuff pretty easy), and finally tell the window
manager / system about its new content orientation by calling

What's missing currently is a way to choose from the application side
whether it wants the system orientation or to do its own rotation, on
platforms that could support both (like iOS).

We have QWindow::orientation() / QWindow::requestOrientation() which
sounds like it might solve the issue, but which has no real
implementation (except in qtwayland, where the information was exposed
on the compositor side but not used in any existing compositor). The
idea with the API was to request a window orientation different from the
screen orientation, and have the compositor or display controller do a
manual 90 degree rotation of the window. The intended use case was
something like a landscape game wishing to port its GLES1 or GLES2 code
to a portrait-primary device. After some discussions we're no longer
sure whether this is the right API to cover iOS and other platforms, and
we would rather revisit the concept for 5.1.

There's of course the option to mark it as obsolete in qdoc, but that
means having to keep it around for the whole 5.x series. The best thing
would be to get rid of the API for 5.0, as done in change

Outside of qtbase (where none of the platform plugins implemented the
feature), and qtwayland (which is not in qt5.git), the API was only
(incorrectly) used in qtmultimedia, which this change addresses:

Development mailing list
Development at qt-project.org

More information about the Development mailing list