The problem is there's no way in those Qt APIs to specify that the QWindow is rotated relative to the QScreen. Qt API assumes that QWindow axes are always perfectly aligned with the QScreen they're in. You can only express that the *contents* of a QWindow are rotated relative to the QScreen.
Unity8 rotates window surfaces on the display. eg: a fullscreen landscape application window in a 500x1000 pixels phone screen will be 1000x500.
Meaning that applications rotated by unity8 never really know they're rotated as they don't have to bother rotating their contents. qtubuntu does some gymnastics in order to produce QScreen values that make the application think it's always matching its QSCreen and thus no content rotation is needed (eg: SDK's OrientationHelper will never think a rotation is needed).
If you really need to know where your window is on the display and how device is oriented, you will need to look elsewhere. Current Qt APIs are not able to provide that.
The problem is there's no way in those Qt APIs to specify that the QWindow is rotated relative to the QScreen. Qt API assumes that QWindow axes are always perfectly aligned with the QScreen they're in. You can only express that the *contents* of a QWindow are rotated relative to the QScreen.
Unity8 rotates window surfaces on the display. eg: a fullscreen landscape application window in a 500x1000 pixels phone screen will be 1000x500.
Meaning that applications rotated by unity8 never really know they're rotated as they don't have to bother rotating their contents. qtubuntu does some gymnastics in order to produce QScreen values that make the application think it's always matching its QSCreen and thus no content rotation is needed (eg: SDK's OrientationHelper will never think a rotation is needed).
If you really need to know where your window is on the display and how device is oriented, you will need to look elsewhere. Current Qt APIs are not able to provide that.