[Sugar-devel] prevent screen rotation in a sugar activity?

[Bakhtiar Mikhak]

On Dec 10, 2010, at 6:09 PM, James Cameron wrote:

> On Fri, Dec 10, 2010 at 05:50:54PM -0500, Bakhtiar Mikhak wrote:
>> If I am reading the current version of HIG correctly, it is not a
>> requirement for developers to implement a portrait layout for their
>> activity:
>> 
>>   Screen Rotation
>> 
>>   While in Hand-held mode, the laptops support screen rotation; by
>>   pressing a small button on the bezel of the display, the interface
>>   will rotate 90 degrees to provide a portrait layout of the
>>   currently active activity. Just as any activity can implement
>>   Hand-held mode, those which can benefit from a vertical aspect
>>   ratio may also implement this feature, and we encourage developers
>>   to take advantage of this functionality.
> 
> Agreed, it is not a requirement for the activity to implement portrait
> layout.  When it is not implemented, part of the activity would be
> invisible after rotation.  The learner will rapidly find the activity
> does not work well when rotated, and will avoid rotating.

I was not suggesting to support a UI rotation without accounting for the change in the dimensions! 

Setting aside the wisdom of iPhone and Android allowing developers control over UI rotation, there are however practical considerations on XOs that lead us to want to disable UI rotation. For example, as one can easily verify in Record and other activities which use Gstreamer, xvimagesink does not rotate its contents. 

Your comments did also make us wonder if the case that you seem to be concerned with can be seen anywhere on the laptop right now. And, we discovered the bug that you can see in [ http://imgur.com/z8s4i ] on the latest Sugar build on an XO-1.5. Note that the speaker icon gets positioned incorrectly after a UI rotation as well. 

We have just filed tickets for these bugs.

>> I therefore think it is worth considering if the control over if/how
>> one's activity takes advantage of screen rotation should be exposed
>> through the Sugar API.
> 
> Sounds good, please propose a design and patch.

There are many people on this list who are more deeply familiar with the Sugar source code and would know best know how to go about doing this, but I am happy to work on it, and it would definitely be a good constructionist learning experience. In the meantime, however, as activity developers with limited time and resources, we were initially asking if this functionality is already supported and exposed through the API.  

The larger point being, sometimes Activity developers would not mind foregoing an opportunity to extend the platform they build on in exchange for access to tools that help them be more expressive and productive with that platform. Inviting our developers to extend the system when they ask whether a feature is supported in the API, however well intentioned and welcoming it is meant to be, can serve as a deterrent. I am sure that is not what we want.