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:
* 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
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
