[Development] Heads up: Late API removal from QWindow

[Samuel Rødal]

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