On Tue, Nov 10, 2009 at 12:08:06PM +0000, Dave Ball wrote: > Rui Miguel Silva Seabra wrote: > > On Tue, Nov 10, 2009 at 12:00:31AM +0000, Dave Ball wrote: > >> option1: New atoms in the _NET_WM_STATE property. > >> - _NET_WM_STATE_LANDSCAPE > >> - _NET_WM_STATE_PORTRAIT > >> > >> If neither is present for a given window, WM can choose (based on > >> the accelerometers). Both present is an error - or could be defined > >> as leave the window in it's current orientation. > >> > >> option2: New property. > >> > >> _NET_WM_ORIENTATION > >> 0 = Either / WM decides > >> 1 = Landscape > >> 2 = Portrait > > > > There are two landscape positions and 2 portrait positions :) > Doh - of course! Which would lead to: > > _NET_WM_STATE_ORIENTATION_LANDSCAPE > _NET_WM_STATE_ORIENTATION_PORTRAIT > _NET_WM_STATE_ORIENTATION_INVERTED > > or > > _NET_WM_ORIENTATION > 0 = Either / WM decides > 1 = Landscape > 2 = Portrait > 3 = Landscape inverted > 4 = Portrait inverted > > However, what's the use-case for an application requesting either of the > inverted states? I can't see when those would be useful - in terms of > hints the app would supply. > > Obviously, if the WM was deciding orientation based on the device > position, you would correctly rotate to the inverted states, but if an > application is built for portrait or landscape is there any reason a > developer would not want the "normal" portrait/landscape orientation for > the device?
Yes, certain devices may be better prepared (in terms of connectivity for power, usb, etc...) for one kind of landscape rather than the other. Rui _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
