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