[maemo-developers] Bug#6203, rotation and OHMD

From: Aniello Del Sorbo anidel at gmail.com
Date: Wed Nov 18 18:34:49 EET 2009
Out of ignorance,

why don't you guys simply allow only the foremost (i.e. the currently
visible one)
application to rotate and send the rotation event to the other apps
AFTER the animation has completed.

After all to switch from one app to the other we've got to go via the
task switcher
and that rotates to landscape mode anyway (at least until you put in support
for rotation there as well, but still..)


2009/11/18 Martin Grimme <martin.grimme at gmail.com>:
> How about another XAtom (since we already have so many on Maemo ;) )
> on the application window, saying "I rotate well and quickly." ?
> The ohmd could take care of this atom and refrain from freezing the
> app during rotation, iff it is the currently visible one.
> Of course applications could lie about their rotation capabilities,
> but that's what we have the extras-testing Q&A for.
> Martin
> 2009/11/18, Eero Tamminen <eero.tamminen at nokia.com>:
>> Hi,
>> ext Eugene Antimirov wrote:
>>>> It handles also audio policies and tries to make sure that you get
>>>> your phone calls when the device is heavily loaded and some other
>>>> minor things.
>>> Just to know.
>>  >
>>> I see now this `ohmd` process in my 41-10. I did not get it, was this
>>> daemon improved or made worse in new firmware released lately?
>> Better for known (pre-installed) applications, worse for unknown
>> applications.  The reason for this is that unknown applications have
>> unknown resource usage so system policy treats them with more care.
>> It's a bit of a chicken and egg problem.  Changing the policy is slow
>> iterative work requiring lots of testing that the policy change doesn't
>> significantly worsen other use-cases in some situations (e.g. for things
>> for which there are certain certification & legal requirements).
>> Developers can now experiment and report/discuss things which they would
>> like policy to handle better (for certain classes of 3rd applications
>> and their use-cases). I.e. in regards to 3rd party applications, the
>> policies could be considered work-in-progress.
>> Things that could potentially be done for 3rd party applications
>> policy handling:
>> - Default policy is improved in regards to unknown processes.
>>    It's yet unknown whether this can be done well enough without
>>    sacrificing the known functionality, that's why feedback is needed
>>    on the behavior of 3rd party application use-cases.
>> - Applications themselves specify the required policy on install.
>>    This is extra work for apps, and requires extensive testing to
>>    guarantee that the policy they choose is good match for
>>    the application in all cases. (application doesn't leak or
>>    otherwise hog resources)
>> - Some way for user to specify per-application policy.
>>    I'm sure power-users would like that... :-)
>>       - Eero
>> _______________________________________________
>> maemo-developers mailing list
>> maemo-developers at maemo.org
>> https://lists.maemo.org/mailman/listinfo/maemo-developers
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers

More information about the maemo-developers mailing list