Ideal screen rotation

Carsten Haitzler (The Rasterman) raster at rasterman.com
Sun Nov 8 02:04:04 CET 2009


On Sat, 7 Nov 2009 14:53:18 +0000 Neil Jerram <neiljerram at googlemail.com> said:

> 2009/11/7 Rui Miguel Silva Seabra <rms at 1407.org>:
> >
> > You have no solution for existing apps other than causing a full
> > stop on rotation once you get the desired rotation (which is what I
> > do for apps that work better on landscape).
> 
> I imagine WM configuration for this, and a shelf gadget to make it
> easy to add to the configuration for an app that doesn't yet have it.
> 
> > DBUS helps a lot because you can define a standard set of signals:
> >  1. screen rotation apps could listen for specific screen rotation signals
> 
> Agree there.  The frequency of the new DBUS orientation interface
> seems high enough for omnewrotate to use it instead of reading
> accelerometer data directly.
> 
> >  2. apps which have specific needs can broadcast said needs to DBUS
> 
> Interesting idea, but different apps can have different specific
> needs, and only the WM knows which app is in the foreground.
> 
> >> Another thought that occurred to me is that if this was a window
> >> manager responsibility, perhaps the window manager could infer
> >> preferred orientation simply from the requested window size?  (i.e.
> >> requesting width > height implies a preference for landscape).
> >
> > The only way this could be the window manager's job, was if the window
> > manager had auto-rotation routings. AFAICT, E doesn't yet.
> 
> I think my other response has covered this.
> 
> > Of course "rotator" apps only come up because people feel the need
> > and writing a simple daemon is simpler than patching a quite evolved
> > window manager.
> 
> Yes, good point.  And I also admit that the work needed for my
> so-called ideal solution is non-trivial, and that the result might
> only be a little better than the existing solution - i.e. to run
> omnewrotate nearly all the time, and only stop it when using an app
> with which it interferes in a bad way.
> 
> But I think I might have a go anyway at patching the e17 WM.  With
> Debian, and 'apt-get source', and gcc on the phone, it shouldn't be as
> hard as it might sound.

e has a whole subsystem for this... "modules". you don't need to patch
anything. modules are runtime patches for the wm. :)

> >> That should often work for apps that were designed for the desktop.  I
> >> would guess that apps written for the FR might not request specific
> >> sizes, because they'd know that they will always be fullscreen anyway
> >> - so for those apps some explicit configuration would be needed
> >> somewhere (prefer-portrait, prefer-landscape, or auto-rotate).
> >
> > So "rotators" would need to parse all the configurations?
> 
> No, the WM (or whatever hook the WM calls out to).
> 
> Regards,
>          Neil
> 
> _______________________________________________
> Openmoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com




More information about the community mailing list