[SailfishDevel] ApplicationWindow.activate() does nothing

[Thomas Tanghus]

On Tuesday 16 June 2015 15:27:15 Richard Grooff wrote:
> Apps can keep it from turning off:
> "req_display_blanking_pause" and when app closes:
> "req_display_cancel_blanking_pause".

Thanks Richard, but I don't want it to stop blanking, as the alarms can be up 
to 1 hour; I rather want it to unblank when the time has passed. Otherwise it 
would drain too much on the battery.

> I use it in harboud-hud version openrepos.

Do you have your code publicly available, so I could see an example on how to 
use it?

> Regards, Richard

/Thomas

> On Tue Jun 16 17:01:13 2015 GMT+0200, Thomas Tanghus wrote:
> > 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 coderusinbox at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20150616/92d56ca2/attachment.pgp>