+1 from my side for removing it in 5.0. Cheers, Lars
On Dec 5, 2012, at 9:12 AM, Samuel Rødal <[email protected]> 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
