On Sat, 7 Nov 2009 14:53:18 +0000 Neil Jerram <[email protected]> said:
> 2009/11/7 Rui Miguel Silva Seabra <[email protected]>: > > > > 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 > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
