On Tuesday 16 June 2015 10:51:29 Simo Piiroinen wrote: > On Tuesday, June 16, 2015 12:25:09 AM Thomas Tanghus wrote: > > On Friday 12 June 2015 12:47:42 coderusin...@gmail.com wrote: > > > check mce dbus. There is should be a method bot unblanking screen. > > > > Been away since Friday, but "req_display_state_on" looks like the one. > > Hi, > > the rule of thumb is: > "User turns display on, apps can keep it from turning off." > > Now, if you still absolutely need to turn display on, then note that:
Thanks a lot for preventing me from pursuing the wrong path, Simo.
When I get the time to work on it again, I guess it will be 2) in lieu of 4) -
but first I have to make a successful dbus call :D
> * Explicit display state requests like req_display_state_on, should be
> avoided - they can cause subtle problems and/or easily end up ignored
> altogether
>
> * Getting display to turn on does not mean the ui can be shown if the
> display/device is locked
>
> Least problematic way depends on what the app is/does - terms of
> similarity to sw existing on the device:
>
> 1) "Just show something on screen if applicable, no user interaction"
> i.e. notification banners and such
>
> Start notification type blanking policy exception for relatively short
> period that is not extended due to touch interaction - display comes
> up during that period when/if sensor states etc allows it
>
> com.nokia.mce.request.notification_begin_req("context", 2500, 0)
>
> The "context" needs to be a string that is unique enough within the
> process that is using it.
>
> If process exits, the exception state is automatically canceled, so
> these can't really be tested with dbus-send & like. The mcetool
> utility can be instructed not to exit when done, so something like
> "mcetool --begin-notification=foo,5000,1000 --block" works.
>
> Note that the app should do this even if the display happens to
> be on to make overlapping notifications work as expected (mce
> blanks display only if it was off at start of the 1st notification).
>
> 2) "Prompt something simple from user" i.e. likes of usb mode
> selection, headset volume warning, etc
>
> Start notification exception with long enough time for user to
> understand what is happening, optionally extend the duration on touch
> interaction (if user needs to type lock code or something)
>
> com.nokia.mce.request.notification_begin_req("context", 15000, 2500)
>
> When done, terminate exception but (optionally) keep the display on
> for a while longer to give user a chance to continue with something
> else without display blanking in between
>
> com.nokia.mce.request.notification_end_req("context", 2500)
>
> 3) "Novel call like ui"
>
> incoming call:
>
> com.nokia.mce.request.req_call_state_change("ringing","normal")
>
> answered/outgoing call:
>
> com.nokia.mce.request.req_call_state_change("active","normal")
>
> call ended:
>
> com.nokia.mce.request.req_call_state_change("none","normal")
>
> The display should turn on/off just like with normal calls.
>
> The call state tracking uses sender identification too, so several
> processes can at least in theory do this without interfering with
> each other. And state gets canceled automatically when process
> drops from system bus, so dbus-send & co will not work.
>
> 4) "Novel alarm like ui"
>
> I guess to get this working properly it would need some new logic in
> timed and/or mce. But the notifiction methods should work to some
> extent.
>
> Hope this helps.
>
> simo
--
Med venlig hilsen / Best regards
Thomas Tanghus
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
