Erik, Here is how you can be notified when the screen is rotated:
First, listen for the "expose" event in PyGTK: self.connect("expose_event", self.area_expose_cb) Here is the method that gets invoked: def area_expose_cb(self, area, event): screen_width = gtk.gdk.screen_width() screen_height = gtk.gdk.screen_height() if self.saved_screen_width != screen_width and self.saved_screen_width != 0: self.show_page(self.page) self.saved_screen_width = screen_width return False Now if you write a PyGTK Activity the layouts usually make this unnecessary. In this case I was displaying an image which needed to be resized to make the best use of the new screen dimensions, so I invoke the method that shows the image when the dimensions change. Every new Activity developer seems to want to do something that Sugar won't allow. In time you'll come to terms with what Sugar is and make your Activities accordingly. Your iPhone and Android examples are not good. If I had paid money for an app for either platform and it refused to rotate when I rotated my phone I would not think highly of that app. Supporting screen rotation in a PyGTK Activity is trivial. With PyGame it's more work, but it's work you should be doing anyway. With Sugar on a Stick your Activity will need to support a variety of screen dimensions. A good example of the wrong thing to do is the commercial game "Super Vampire Ninja Zero". It ONLY works on the XO screen dimensions, without rotation. Don't be that guy! James Simmons On Fri, Dec 10, 2010 at 4:14 PM, James Cameron <qu...@laptop.org> wrote: > On Fri, Dec 10, 2010 at 04:29:31PM -0500, Erik Blankinship wrote: >> It is sometimes a designer's prerogative to present their work in one format. >> Numerous examples are available on the iPhone and android markets. > > It is sometimes a platform designer's perogative to enforce human > interface guidelines and require applications to support certain > behaviours. > >> Is it possible to override or be notified of a rotation signal? > > No, not without taking control of components outside the scope of a > Sugar activity. You're welcome to try that, but the problems that occur > are: > > 0. installation will require root access, which is not available to > some users due to deployment team policy, > > 1. the API will keep changing, instead of remaining relatively static > in the case of the Sugar Activity API, > > 2. there are multiple build versions to test against, > > 3. there is a higher risk of breaking something later. > > -- > James Cameron > http://quozl.linux.org.au/ > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel