[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.
Cheers,
Lars
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