Ideal screen rotation
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Sun Nov 8 01:59:43 CET 2009
On Sat, 7 Nov 2009 14:23:01 +0000 Neil Jerram <neiljerram at googlemail.com> said:
> 2009/11/7 Rui Miguel Silva Seabra <rms at 1407.org>:
> > I'm definitely not following you... I envision the following scenario
> > according to what you say, could you please elaborate on why it wouldn't
> > happen this way?
> My thinking is evolving with this discussion, but my current idea of
> the solution is that the WM controls whether omnewrotate is running
> (or equivalent, but for simplicity let's just say omnewrotate).
> So for the current foreground app, the WM determines (from properties,
> or width:height, or configuration, or some customization hook, or from
> user direction via a shelf gadget) which of the following applies.
> 1. App works best in landscape.
> 2. App works best in portrait.
> 3. App can adapt to either landscape or portrait, and user should
> choose by turning the phone round.
> Then, for (1) and (2), the WM itself calls xrandr to set the correct
> orientation, and kills omnewrotate if it was running. For (3) the WM
> starts omnewrotate if it isn't already running, and omnewrotate then
> handles autorotation.
no. this is way too ugly.
1. omnewroatte ONLY listens to accelerometers and talks to the wm (via any
mechanism you like) telling it what position the phone is in. that is all it
does. nothing else. all other decisions are made by the wm base on as you said
above, the properties of the window - which app is currently active (change
apps between one that wants to be portrait wants to be landscape, the wm has to
flip orientation when you flip apps. etc. for example - e already has a config
dialog for changing screen resoltion and rotation. it already handles this
stuff - it's missing the logic of reading some as-yet-uninvented property from
a window and 2. handling that property with respect to rotation. any wm can do
this. this is definitely a job that belongs in properties of a window and the
wm to read them, follow their changes, and "do the right thing")
> Given that...
> > 1. App wants to be landscape, sets property on window
> WM would call xrandr itself.
> > 2. "rotator" determines the phone is in portrait, rotates.
> omnewrotate wouldn't be running, so this wouldn't happen.
> > Now what happens?
> > 3. App is landscape, but screen is portrait: fail
> WM calls xrandr to go to landscape.
> > or
> > 3. Window manager overrides rotation
> > 3.1 but "rotator" determines portrait, rotates again
> As above, omnewrotate wouldn't actually be running, so wouldn't do this.
> I hope that helps to clarify what I have in mind!
> Openmoko community mailing list
> community at lists.openmoko.org
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
More information about the community