[Development] Heads up: Late API removal from QWindow

[Hausmann Simon]

+1

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.



Simon


________________________________________
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

Hello,

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
QWindow::reportContentOrientation().

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
https://codereview.qt-project.org/#change,41875

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:
https://codereview.qt-project.org/#change,41874

--
Samuel
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development