[Development] Heads up: Late API removal from QWindow

Knoll Lars Lars.Knoll at digia.com
Wed Dec 5 23:07:11 CET 2012

+1 from my side for removing it in 5.0.


On Dec 5, 2012, at 9:12 AM, Samuel Rødal <samuel.rodal at digia.com> wrote:

> 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

More information about the Development mailing list