M10 tablet does not respect the orientation specified in .desktop file

Confirmed, I believe this happened with the new side stage implementation.

I'd argue we should force portrait apps into the side stage. As you rotate the device into portrait, they would fill the screen.

Similarly, those whose maxWidth/Height suggests they should be in side stage should probably go in there - not sure if we lock the device into landscape then, or pillar/letter-box the app at its maximum size?

The two above deserve a separate bug - for now we need to make sure that portrait apps force the device into portrait.

For now portrait apps will default to Side stage.

This bug was fixed in the package unity8 - 8.12+16.10.20160627.5-0ubuntu1

---------------
unity8 (8.12+16.10.20160627.5-0ubuntu1) yakkety; urgency=medium

  [ Albert Astals Cid ]
  * Stop watching the old header item height once it's not our header
    anymore
  * LVWPH: cull the header item when not on view to save some painting
  * Adapt test to new mock behaviour
  * Don't let the mouse go outside the parentItem (LP: #1525350)
  * Use non deprecated package names
  * Mark system includes as such
  * Fix initialization order warning
  * Do not rely on deleteLater not crashing on null pointers
  * Add more headers of classes we use for automoc to be run
  * CardTool: Fix the fallback value to be a size and not an integer
  * CardTool: Include Ubuntu Components since we're using units.gu
  * Rework tst_PreviewRatingDisplayCreationRanges

  [ Daniel d'Andrada ]
  * Cursor: Let AnimatedSprite run only on animated cursors and while
    the display is on (LP: #1588873, #1594358)
  * Fix missing screenshot when orientation changes while shell rotation
    ongoing (LP: #1587796)

  [ Josh Arenson ]
  * Make PreviewRatingSingleDisplay visible again after editing a
    review. (LP: #1587097)
  * Correct errors in all png images to prevent libpng warnings.

  [ Lukáš Tinkl ]
  * Fix some smaller issues with OOBE wizard password pages (LP:
    #1590467)
  * Prevent mouse wheel events from going through shell elements (LP:
    #1536268)
  * Do not let mouse and wheel events pass thru the titlebar (LP:
    #1588424)
  * Hide the maximize window button based on size restrictions (LP:
    #1541982)

  [ Marco Trevisan (Treviño) ]
  * Unity8.conf: ensure MIR_SOCKET is set for future customers (such as
    the dash)
  * ClientIndicator: be more informative about loading failures for
    dynamically created objects

  [ Michael Terry ]
  * Stop unity8 from getting in a "switch-to-greeter" loop when locking
    on a desktop. (LP: #1593718)

  [ Michael Zanetti ]
  * set minimum window sizes on dash
  * displace application windows when the OSK would cover them

  [ Nick Dedekind ]
  * Force dash to always stay in the main stage. (lp:#1592404) (LP:
    #1592404)
  * Save the last surface stage on stage drop. (LP: #1579003)
  * Default portrait only apps to the side stage. (LP: #1573153)

  [ Albert Astals Cid, Andrea Cimitan, Michał Sawicz, Nick Dedekind ]
  * Added live video playback in dash previews

 -- Michael Zanetti <email address hidden> Mon, 27 Jun 2016 18:48:59 +0000

Is this suppose to already work on M10 rc-proposed (r137)?

Yes it is, and it does for me, do you have an example that doesn't?

Note that this is the default you can still force it to landscape, and the next time it runs it will also use landscape.

I was trying with Clock app but as you said I had it in landscape before and it always reopened that way. I created a new app with portrait only setting and it works: it starts in the side panel when the tablet is in landscape.
Thanks Pat and sorry for my confusion. Also I hope at some point the bug will be properly fixed :)

> Also I hope at some point the bug will be properly fixed :)

What would you say would be "properly fixed" here?

To have an app locked to portrait if it's specified in .desktop file. Or even better to have bug #1382209 fixed.

> To have an app locked to portrait if it's specified in .desktop file.

The problem is this would impose an unnecessary restriction on the user, where the app can work just fine in the side stage - it is in portrait there. Ultimately it's the user's choice and we want to respect that. What would be your issue with this remaining as it is?

> Or even better to have bug #1382209 fixed.

Not sure that will change much?

For example Falldown does not work properly in landscape as it has "gravity" of the falling ball going sideways.
For me personally Big Moving Text does not work. It has an option to display scrolling text and a user can set if she/he wants it in landscape or in portrait. It works as expected if the orientation is locked to portrait but does not if a user rotates to landscape. Apart from getting the right orientation problem, there's also an issue with an app being in the side stage. It can't go full screen from there.

> For example Falldown does not work properly in landscape as it has
> "gravity" of the falling ball going sideways.

I'd say that's partially an app bug, we let it know what orientation the device is in and it should translate the accelerometer data.

> For me personally Big Moving Text does not work. It has an option to
> display scrolling text and a user can set if she/he wants it in
> landscape or in portrait. It works as expected if the orientation is
> locked to portrait but does not if a user rotates to landscape.

Same here, it should translate what "landscape" and "portrait" means.

> Apart from getting the right orientation problem, there's also an
> issue with an app being in the side stage. It can't go full screen
> from there.

That's a separate bug indeed - fullscreen should be fullscreen, whether you were originally in side or main stage.

That said, I'm not married to the idea - ultimately we want to leave more freedom to the user, somewhat forcing the app developers to do a slightly better job. But if it proves more problematic than useful, we can always reconsider.

Maybe we need an additional switch in the display indicator that would indicate the app's preference for display orientation, but allow the user to force it off.

Personally I hate apps forcing an orientation on me just because they can.