ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

Hey Nekhelesh,

thanks for bringing up the topic here. Some questions that came to my
mind when reading your mail:

  (1.) Would you expect the screen to stay bright when in night-mode?
If not, I wonder if a darkened background makes sense at all, as the
displays would autodim.

  (2.) Using the phone as a clock stand is certainly a good idea. Did
you (as in you and design) explore the idea of leveraging the
proximity sensor to briefly turn on the screen when the user "waves"
in front of the phone?

One problem I see is: Today, the screen is kept on during periods of
activity, where activity could be:

  * user interaction
  * video playback
  * ongoing call

All of these activities have in common that it simple to detect when
they end. In the night-mode case, I have difficulties identifying
criteria to be able to decide "night mode activity ended", except for
a timeout (which then the users might want to adjust etc.).

On Wed, Jun 4, 2014 at 3:25 PM, Nekhelesh Ramananthan
<krnekhelesh@xxxxxxxxx> wrote:
> Hey everyone,
>
> During the sprint at Malta, we were given new designs for the clock app. It
> introduces a new mode called the "Night Mode" where the user can use the
> phone as a clock stand. In the Night Mode, the clock app will show a basic
> clock with all other UI elements hidden and also use a dark background. It
> is however important that the screen remains on all the time. I still need
> to confirm with design, how long they want the screen to be on. As I
> understand, currently it is not possible for an app to request the screen to
> be on. I discussed this with Jamie Strandboge and Jim Hodapp. I was told
> that the media-hub makes dbus calls to powerd to keep the screen on when a
> video is being played on the phone. So I am hoping we can do something
> similar for the clock app.
>
> Jamie informed me that 3rd apps cannot make direct calls to powerd while
> being confined. So there are some options that come to mind,
>
> Let the clock app run unconfined to make direct calls to powerd. This was
> also done by the music-app until recently when they switched to music-hub.
> It is not the ideal situation as advised by Jamie.
> Create a restricted policy group which allows making calls to powerd.
> Implement a intermediary (power-hub) in between confined apps and powerd
>
> The best temporary solution may be the restricted policy group in my
> opinion. However I feel that the 3rd solution might be a better option in
> the long run since 3rd apps might like to have that control as well.
>

While it is certainly possible to implement the exception as a viable
short-term solution, it would also push the burden on the app to do
the right thing (tm). While I'm certain that you will take care of the
Clock app and its responsibilities, the assumption does not hold in
the general case.

That being said, I would prefer the 3rd option. We have been talking
about making powerd policy-based, handling events and tracking
activities to take power-related decisions. However, even if that
happens, we still would have to come up with a good heuristic to
determine the "end" of the clock app's "night mode".

One alternative approach could be to allow the app to request an
app-specific idle timeout within reasonable limits.
That would also help in solving Oliver's ebook-reader use-case.

HTH,

  Thomas

> Hopefully we can discuss here what other solution are available and come to
> a resolution soon.
>
> Cheers,
> Nekhelesh
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>