Ideal screen rotation

[Neil Jerram]

Having just written an automatic screen rotation program (like
omnewrotate), I'm now wondering about the best way of using it, so
that everything Just Works the way that it should.

In particular, I've realized now that

- for many apps there is a preferred orientation (e.g. zhone and
hex-a-hop), and the best thing is to rotate the screen to what is best
for each app, regardless of how the phone is being held

- for some apps you definitely don't want the screen to be rotated
underneath them, e.g. mokomaze

- for the apps where autorotation makes sense, you want the control to
be easily accessible - certainly a lot easier than switching back to
the launcher or an xterm and doing something there :-)

Have others already thought about this and devised solutions?

I think a good solution might involve the window manager - since the
window manager knows which app is at the front of the screen and so
could rotate the screen correctly for it (including enabling
autorotation for the apps where that makes sense).  Alternatively - at
least for e17 - an easily accessible gadget in the top shelf could
make it very simple to choose a specific orientation and to enable and
disable autorotation.

Regards,
         Neil

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Tue, Nov 03, 2009 at 07:40:58PM +0000, Neil Jerram wrote:
> - for many apps there is a preferred orientation (e.g. zhone and
> hex-a-hop), and the best thing is to rotate the screen to what is best
> for each app, regardless of how the phone is being held

When this is the case, I stop omnewrotate.

> - for some apps you definitely don't want the screen to be rotated
> underneath them, e.g. mokomaze

Idem.

> - for the apps where autorotation makes sense, you want the control to
> be easily accessible - certainly a lot easier than switching back to
> the launcher or an xterm and doing something there :-)
>
> Have others already thought about this and devised solutions?
>
> I think a good solution might involve the window manager - since the
> window manager knows which app is at the front of the screen and so
> could rotate the screen correctly for it (including enabling
> autorotation for the apps where that makes sense).  Alternatively - at
> least for e17 - an easily accessible gadget in the top shelf could
> make it very simple to choose a specific orientation and to enable and
> disable autorotation.

The icon in the launcher being a toggler for omnewrotate is a "hack" as
I haven't learned how to make a shelf gadget yet.

Patches to make a shelf gadget for omnewrotate are, of course, welcome :)

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Patryk Benderz]

[cut]
> autorotation for the apps where that makes sense).  Alternatively - at
> least for e17 - an easily accessible gadget in the top shelf could
What about full screen appications? Maybe using AUX button is a
solution?


--
Patryk "LeadMan" Benderz
Linux Registered User #377521
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Email secured by Check Point

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Helge Hafting]

Neil Jerram wrote:

> Having just written an automatic screen rotation program (like
> omnewrotate), I'm now wondering about the best way of using it, so
> that everything Just Works the way that it should.
>
> In particular, I've realized now that
>
> - for many apps there is a preferred orientation (e.g. zhone and
> hex-a-hop), and the best thing is to rotate the screen to what is best
> for each app, regardless of how the phone is being held
>
> - for some apps you definitely don't want the screen to be rotated
> underneath them, e.g. mokomaze
>
> - for the apps where autorotation makes sense, you want the control to
> be easily accessible - certainly a lot easier than switching back to
> the launcher or an xterm and doing something there :-)
>
> Have others already thought about this and devised solutions?
>
> I think a good solution might involve the window manager - since the
> window manager knows which app is at the front of the screen and so
> could rotate the screen correctly for it (including enabling
> autorotation for the apps where that makes sense).  Alternatively - at
> least for e17 - an easily accessible gadget in the top shelf could
> make it very simple to choose a specific orientation and to enable and
> disable autorotation.

The software that control rotation need to know if the foreground app
should run in landscape, portrait or auto mode. (And perhaps the
upside-down variants as well.)

There are many ways to do this. For example:

1. Add this to enlightenment.
    Advantages: e already knows at all times
                which app is in the foreground. The .desktop
                files in /usr/share/applications/ can specify
                rotation preferences.
                You can also have rotation gadgets on the
                top shelf, for overriding when necessary.
    Disadvantage: Works only with e - obviously.

2. Give omnewrotate (or similiar rotation app) a list of apps and their
    preferred rotation.
    Advantage: works for all window managers
    disadvantage: overriding the rotation could be trickier, and
                  omnewrotate will need a way to get notified about
                  focus/foreground changes. Fast polling will slow down
                  the phone, slow polling will be too slow. So
                  notification is necessary.

Helge Hafting


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting wrote:

> > Have others already thought about this and devised solutions?
> >
> > I think a good solution might involve the window manager - since the
> > window manager knows which app is at the front of the screen and so
> > could rotate the screen correctly for it (including enabling
> > autorotation for the apps where that makes sense).  Alternatively - at
> > least for e17 - an easily accessible gadget in the top shelf could
> > make it very simple to choose a specific orientation and to enable and
> > disable autorotation.
>
> The software that control rotation need to know if the foreground app
> should run in landscape, portrait or auto mode. (And perhaps the
> upside-down variants as well.)

Or, what I think would be the proper way to do it, the application should
broadcast to dbus that it prefers no rotation, or one of the 4 possible
rotation states and omnewrotate could listen to such requests and
not rotate while there is such a message in the bus.

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Petr Vanek]

>> The software that control rotation need to know if the foreground app
>> should run in landscape, portrait or auto mode. (And perhaps the
>> upside-down variants as well.)
>
>Or, what I think would be the proper way to do it, the application
>should broadcast to dbus that it prefers no rotation, or one of the 4
>possible rotation states and omnewrotate could listen to such requests
>and not rotate while there is such a message in the bus.

so how does framework fit to this with it's orientation interface?

Petr



_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Wed, Nov 04, 2009 at 02:22:33PM +0100, Petr Vanek wrote:

> >> The software that control rotation need to know if the foreground app
> >> should run in landscape, portrait or auto mode. (And perhaps the
> >> upside-down variants as well.)
> >
> >Or, what I think would be the proper way to do it, the application
> >should broadcast to dbus that it prefers no rotation, or one of the 4
> >possible rotation states and omnewrotate could listen to such requests
> >and not rotate while there is such a message in the bus.
>
> so how does framework fit to this with it's orientation interface?

As far as I know, FSO will only emit some signals from time to time saying
what position it thinks it's on. Other programs can plug into it and decide
what to do (but of course that isn't at a rate useful for gestures).

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Petr Vanek]

>> so how does framework fit to this with it's orientation interface?
>
>As far as I know, FSO will only emit some signals from time to time
>saying what position it thinks it's on. Other programs can plug into
>it and decide what to do (but of course that isn't at a rate useful
>for gestures).

i am testing that interface now and it reports position in less then 2
seconds (which i consider very optimal for regular usage). what kind
of gestures do you mean or what do you mean by gestures?

Petr


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Wed, Nov 04, 2009 at 02:47:02PM +0100, Petr Vanek wrote:

> >> so how does framework fit to this with it's orientation interface?
> >
> >As far as I know, FSO will only emit some signals from time to time
> >saying what position it thinks it's on. Other programs can plug into
> >it and decide what to do (but of course that isn't at a rate useful
> >for gestures).
>
> i am testing that interface now and it reports position in less then 2
> seconds (which i consider very optimal for regular usage). what kind
> of gestures do you mean or what do you mean by gestures?

Look for accelges (for an example).

You need a lot more finegrained readings (several per second) in order
to understand adequately a gesture (example, shaking the freerunner,
doing an L in the air, etc...)

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Petr Vanek]

>Look for accelges (for an example).
>
>You need a lot more finegrained readings (several per second) in order
>to understand adequately a gesture (example, shaking the freerunner,
>doing an L in the air, etc...)

oh yes, agree, but this is complicated and has nothing to do with simple
screen rotation per application/user needs which i thought this thread
was about?

Petr


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Wed, Nov 04, 2009 at 03:50:55PM +0100, Petr Vanek wrote:
> >Look for accelges (for an example).
> >
> >You need a lot more finegrained readings (several per second) in order
> >to understand adequately a gesture (example, shaking the freerunner,
> >doing an L in the air, etc...)
>
> oh yes, agree, but this is complicated and has nothing to do with simple
> screen rotation per application/user needs which i thought this thread
> was about?

Nothing much, really, which is why it was a mere comment between parenthesis,
you asked, I replied :)

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Petr Vanek]

>> oh yes, agree, but this is complicated and has nothing to do with
>> simple screen rotation per application/user needs which i thought
>> this thread was about?
>
>Nothing much, really, which is why it was a mere comment between
>parenthesis, you asked, I replied :)

:)

Petr


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Helge Hafting]

Rui Miguel Silva Seabra wrote:
> On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting wrote:
[...]
>> The software that control rotation need to know if the foreground app
>> should run in landscape, portrait or auto mode. (And perhaps the
>> upside-down variants as well.)
>
> Or, what I think would be the proper way to do it, the application should
> broadcast to dbus that it prefers no rotation, or one of the 4 possible
> rotation states and omnewrotate could listen to such requests and
> not rotate while there is such a message in the bus.

Well, you cannot expect every app to have such preferences, this device
runs generic linux apps that aren't made specially for the freerunner.
Now, of course the app loader can do this, similiar to how we already
request the cpu/backlight when launching some apps.

But there is a problem. The user may switch between several apps with
different rotation needs. (xmahjongg needs landscape, tetris needs
portrait, ...)  How will omnewrotate be notified about this?

Helge Hafting

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:

> Rui Miguel Silva Seabra wrote:
> > On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting wrote:
> [...]
> >> The software that control rotation need to know if the foreground app
> >> should run in landscape, portrait or auto mode. (And perhaps the
> >> upside-down variants as well.)
> >
> > Or, what I think would be the proper way to do it, the application should
> > broadcast to dbus that it prefers no rotation, or one of the 4 possible
> > rotation states and omnewrotate could listen to such requests and
> > not rotate while there is such a message in the bus.
>
> Well, you cannot expect every app to have such preferences, this device
> runs generic linux apps that aren't made specially for the freerunner.
> Now, of course the app loader can do this, similiar to how we already
> request the cpu/backlight when launching some apps.
>
> But there is a problem. The user may switch between several apps with
> different rotation needs. (xmahjongg needs landscape, tetris needs
> portrait, ...)  How will omnewrotate be notified about this?

The proper way is to define a set of DBUS signals.

Of course conflicting signals need to be ignored.

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Neil Jerram]

2009/11/6 Rui Miguel Silva Seabra <[hidden email]>:

> On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:
>>
>> Well, you cannot expect every app to have such preferences, this device
>> runs generic linux apps that aren't made specially for the freerunner.
>> Now, of course the app loader can do this, similiar to how we already
>> request the cpu/backlight when launching some apps.
>>
>> But there is a problem. The user may switch between several apps with
>> different rotation needs. (xmahjongg needs landscape, tetris needs
>> portrait, ...)  How will omnewrotate be notified about this?
>
> The proper way is to define a set of DBUS signals.

Thanks to everyone for your replies on this topic.

I agree with Helge, in that I don't think DBUS is a good solution,
because I really want a solution that works for existing apps.

I suppose for existing apps there could be a DBUS proxy that somehow
works out the best orientation and then sends a DBUS signal on the
app's behalf.  But that seems complicated.

Also I'm not sure why DBUS helps at all.  Once a program somewhere has
worked out the best orientation, why not just call xrandr directly?

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).

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).

Regards,
      Neil

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Carsten Haitzler (The Rasterman)-2]

On Fri, 6 Nov 2009 17:22:27 +0000 Rui Miguel Silva Seabra <[hidden email]> said:

> On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:
> > Rui Miguel Silva Seabra wrote:
> > > On Wed, Nov 04, 2009 at 01:55:29PM +0100, Helge Hafting wrote:
> > [...]
> > >> The software that control rotation need to know if the foreground app
> > >> should run in landscape, portrait or auto mode. (And perhaps the
> > >> upside-down variants as well.)
> > >
> > > Or, what I think would be the proper way to do it, the application should
> > > broadcast to dbus that it prefers no rotation, or one of the 4 possible
> > > rotation states and omnewrotate could listen to such requests and
> > > not rotate while there is such a message in the bus.
> >
> > Well, you cannot expect every app to have such preferences, this device
> > runs generic linux apps that aren't made specially for the freerunner.
> > Now, of course the app loader can do this, similiar to how we already
> > request the cpu/backlight when launching some apps.
> >
> > But there is a problem. The user may switch between several apps with
> > different rotation needs. (xmahjongg needs landscape, tetris needs
> > portrait, ...)  How will omnewrotate be notified about this?
>
> The proper way is to define a set of DBUS signals.
>
> Of course conflicting signals need to be ignored.

no. the proper way is to set properties on your window. this is a display
system thing. dbus is orthogonal to it. you set properties. you let the wm
figure out what to do with the active window(s) based on their properties.

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [hidden email]


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Carsten Haitzler (The Rasterman)-2]

On Fri, 6 Nov 2009 20:24:13 +0000 Neil Jerram <[hidden email]> said:

> 2009/11/6 Rui Miguel Silva Seabra <[hidden email]>:
> > On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:
> >>
> >> Well, you cannot expect every app to have such preferences, this device
> >> runs generic linux apps that aren't made specially for the freerunner.
> >> Now, of course the app loader can do this, similiar to how we already
> >> request the cpu/backlight when launching some apps.
> >>
> >> But there is a problem. The user may switch between several apps with
> >> different rotation needs. (xmahjongg needs landscape, tetris needs
> >> portrait, ...)  How will omnewrotate be notified about this?
> >
> > The proper way is to define a set of DBUS signals.
>
> Thanks to everyone for your replies on this topic.
>
> I agree with Helge, in that I don't think DBUS is a good solution,
> because I really want a solution that works for existing apps.
>
> I suppose for existing apps there could be a DBUS proxy that somehow
> works out the best orientation and then sends a DBUS signal on the
> app's behalf.  But that seems complicated.
>
> Also I'm not sure why DBUS helps at all.  Once a program somewhere has
> worked out the best orientation, why not just call xrandr directly?
>
> 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).
>
> 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).

repeating... "property on window". the rotation preferences are a property of a
window - like min and max size are, its title, etc. etc. - stick it on the
window. ignore dbus. this is not something you do by dbus.

if something is related to the display - especially something is related to
your window, your domain for advertising state, information, making requests
and getting replies is the x11 domain as long as you are using x11. :)

--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [hidden email]


_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Neil Jerram]

2009/11/7 Carsten Haitzler <[hidden email]>:
>
> no. the proper way is to set properties on your window.

How exactly does that (setting a property) happen though?  Is it
something that the app would normally do in its own startup code?  (I
presume yes.)  For apps that don't already do this - and which we'd
ideally like to support without having to modify them all - is there a
way that a proxy could do it for them?

Also do you know if there's already a well-known window property for
preferred rotation, or would we be inventing a new one?

Thanks,
      Neil

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Sat, Nov 07, 2009 at 11:49:18AM +1100, Carsten Haitzler wrote:

> On Fri, 6 Nov 2009 20:24:13 +0000 Neil Jerram <[hidden email]> said:
> > 2009/11/6 Rui Miguel Silva Seabra <[hidden email]>:
> > > On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:
> > >> Well, you cannot expect every app to have such preferences, this device
> > >> runs generic linux apps that aren't made specially for the freerunner.
> > >> Now, of course the app loader can do this, similiar to how we already
> > >> request the cpu/backlight when launching some apps.
> > >>
> > >> But there is a problem. The user may switch between several apps with
> > >> different rotation needs. (xmahjongg needs landscape, tetris needs
> > >> portrait, ...)  How will omnewrotate be notified about this?
> > >
> > > The proper way is to define a set of DBUS signals.
> >
> > Thanks to everyone for your replies on this topic.
> >
> > I agree with Helge, in that I don't think DBUS is a good solution,
> > because I really want a solution that works for existing apps.
> >
> > I suppose for existing apps there could be a DBUS proxy that somehow
> > works out the best orientation and then sends a DBUS signal on the
> > app's behalf.  But that seems complicated.
> >
> > Also I'm not sure why DBUS helps at all.  Once a program somewhere has
> > worked out the best orientation, why not just call xrandr directly?
> >
> > 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).
> >
> > 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).
>
> repeating... "property on window". the rotation preferences are a property of a
> window - like min and max size are, its title, etc. etc. - stick it on the
> window. ignore dbus. this is not something you do by dbus.
>
> if something is related to the display - especially something is related to
> your window, your domain for advertising state, information, making requests
> and getting replies is the x11 domain as long as you are using x11. :)

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?

 1. App wants to be landscape, sets property on window
 2. "rotator" determines the phone is in portrait, rotates.

Now what happens?

 3. App is landscape, but screen is portrait: fail

or

 3. Window manager overrides rotation
 3.1 but "rotator" determines portrait, rotates again
 3.2 go to 3: fail

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community

[Rui Miguel Silva Seabra]

On Fri, Nov 06, 2009 at 08:24:13PM +0000, Neil Jerram wrote:

> 2009/11/6 Rui Miguel Silva Seabra <[hidden email]>:
> > On Fri, Nov 06, 2009 at 04:40:04PM +0100, Helge Hafting wrote:
> >>
> >> Well, you cannot expect every app to have such preferences, this device
> >> runs generic linux apps that aren't made specially for the freerunner.
> >> Now, of course the app loader can do this, similiar to how we already
> >> request the cpu/backlight when launching some apps.
> >>
> >> But there is a problem. The user may switch between several apps with
> >> different rotation needs. (xmahjongg needs landscape, tetris needs
> >> portrait, ...)  How will omnewrotate be notified about this?
> >
> > The proper way is to define a set of DBUS signals.
>
> Thanks to everyone for your replies on this topic.
>
> I agree with Helge, in that I don't think DBUS is a good solution,
> because I really want a solution that works for existing apps.

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 suppose for existing apps there could be a DBUS proxy that somehow
> works out the best orientation and then sends a DBUS signal on the
> app's behalf.  But that seems complicated.

Not smart either, because you'd have a buttload of work for little gain,
and there will always be one more app which isn't supported yet, etc...

> Also I'm not sure why DBUS helps at all.  Once a program somewhere has
> worked out the best orientation, why not just call xrandr directly?

DBUS helps a lot because you can define a standard set of signals:
  1. screen rotation apps could listen for specific screen rotation signals
  2. apps which have specific needs can broadcast said needs to DBUS

This means minimal aditional work for everyone.

> 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.

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.

> 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? I still think
DBUS is the way to do it well, but I'm open for proof otherwise.

Rui

_______________________________________________
Openmoko community mailing list
[hidden email]
http://lists.openmoko.org/mailman/listinfo/community