Re: [SailfishDevel] ApplicationWindow.activate() does nothing
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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
Apps can keep it from turning off: req_display_blanking_pause and when app closes: req_display_cancel_blanking_pause. I use it in harboud-hud version openrepos. Regards, Richard 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 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 Tanghu -- Sent from my Jolla ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
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 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
Hey Thomas,
Unfortunately not publicly available. Relevant part is:
==import QtQuick 2.0
import Sailfish.Silica 1.0
import org.nemomobile.dbus 1.0
Page {
id: page property alias blankingtimer : timer Component.onCompleted: {
positionSource.start()
timer.restart()
}
onStatusChanged: timer.restart() Component.onDestruction: {
positionSource.stop()
//screenSaver.setScreenSaverDelayed(false)
timer.stop()
} Timer { id: timer
property alias suspend: timer.running interval : 600
repeat : true
triggeredOnStart: true
onTriggered: dbus.call(req_display_blanking_pause, undefined)
onRunningChanged: {
if (!running){
dbus.call(req_display_cancel_blanking_pause, undefined)
}
} property DBusInterface _dbus: DBusInterface{
id: dbus destination: com.nokia.mce
path: /com/nokia/mce/request
iface: com.nokia.mce.request busType:
DBusInterface.SystemBus }
}
=
I would expect you can find the required command at:
https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h
Regards, Richard From: Thomas Tanghus tho...@tanghus.net
To: Sailfish OS Developers devel@lists.sailfishos.org
Sent: Tuesday, June 16, 2015 7:55 PM
Subject: Re: [SailfishDevel] ApplicationWindow.activate() does nothing
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 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
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. Hard to find any real documentation on mce other than searching github etc. I've never tried programming anything using dbus. I've read a bit up on it now :) -- 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
It still does nothing. And anyways when being in ApplicationWindow context it shouldn't be necessary? On Friday 12 June 2015 02:20:15 coderusin...@gmail.com wrote: you should call app.activate() The documentation says: activate() Brings the application in full-screen mode to the foreground. But absolutely nothing happens when I call it. Is anybody using it successfully? https://github.com/tanghus/kitchen-timer-qml/blob/master/qml/harbour-kitchen timer.qml#L271 -- 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
Works for me flawlessly. If you’re using Emulator just ignore bugs you founding. Sent from Windows Mail From: Thomas Tanghus Sent: Friday, June 12, 2015 3:00 PM To: devel@lists.sailfishos.org It still does nothing. And anyways when being in ApplicationWindow context it shouldn't be necessary? On Friday 12 June 2015 02:20:15 coderusin...@gmail.com wrote: you should call app.activate() The documentation says: activate() Brings the application in full-screen mode to the foreground. But absolutely nothing happens when I call it. Is anybody using it successfully? https://github.com/tanghus/kitchen-timer-qml/blob/master/qml/harbour-kitchen timer.qml#L271 -- Med venlig hilsen / Best regards Thomas Tanghus___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
On Friday 12 June 2015 10:04:18 coderusin...@gmail.com wrote: Works for me flawlessly. Weird. Do you have a link to an example? If you’re using Emulator just ignore bugs you founding. I always deploy as RPM on the phone. Sent from Windows Mail It's really not good for mailing lists. I spend more time formatting the reply than actually replying :P It still does nothing. And anyways when being in ApplicationWindow context it shouldn't be necessary? On Friday 12 June 2015 02:20:15 coderusin...@gmail.com wrote: you should call app.activate() -- 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
Firstly: *Sorry for the noise* On Friday 12 June 2015 10:46:56 coderusin...@gmail.com wrote: What example you want? For me just appWindow.activate() works. Forget it. I haven't touched the code for over a year, so I had forgotten that there are two places where the alarm could be triggered depending on the precision of libiphb. Sadly it only works when the display is on, not when waking up from deep sleep. I wonder if there's a way to activate the display? Again, sorry for bothering you with my own bad memory :P And I have no idea what wrong with my mail. Using builtin Win8.1 mail client. The HTML mails doesn't support proper quoting as seen in this reply. I can probably get around that by setting my MUA up to only show HTML for certain addresses. I recently had to do a fresh install on a new PC, as my cheap ALDI PC decided to die an untimely death; just haven't gotten around to do the final setup. Sent from Windows Mail From: Thomas Tanghus Sent: Friday, June 12, 2015 3:17 PM To: devel@lists.sailfishos.org On Friday 12 June 2015 10:04:18 coderusin...@gmail.com wrote: Works for me flawlessly. Weird. Do you have a link to an example? If you’re using Emulator just ignore bugs you founding. I always deploy as RPM on the phone. Sent from Windows Mail It's really not good for mailing lists. I spend more time formatting the reply than actually replying :P It still does nothing. And anyways when being in ApplicationWindow context it shouldn't be necessary? On Friday 12 June 2015 02:20:15 coderusin...@gmail.com wrote: you should call app.activate() -- Med venlig hilsen / Best regards Thomas Tanghus -- 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
check mce dbus. There is should be a method bot unblanking screen. Sent from Windows Mail From: Thomas Tanghus Sent: Friday, June 12, 2015 5:32 PM To: devel@lists.sailfishos.org Firstly: *Sorry for the noise* On Friday 12 June 2015 10:46:56 coderusin...@gmail.com wrote: What example you want? For me just appWindow.activate() works. Forget it. I haven't touched the code for over a year, so I had forgotten that there are two places where the alarm could be triggered depending on the precision of libiphb. Sadly it only works when the display is on, not when waking up from deep sleep. I wonder if there's a way to activate the display? Again, sorry for bothering you with my own bad memory :P And I have no idea what wrong with my mail. Using builtin Win8.1 mail client. The HTML mails doesn't support proper quoting as seen in this reply. I can probably get around that by setting my MUA up to only show HTML for certain addresses. I recently had to do a fresh install on a new PC, as my cheap ALDI PC decided to die an untimely death; just haven't gotten around to do the final setup. Sent from Windows Mail From: Thomas Tanghus Sent: Friday, June 12, 2015 3:17 PM To: devel@lists.sailfishos.org On Friday 12 June 2015 10:04:18 coderusin...@gmail.com wrote: Works for me flawlessly. Weird. Do you have a link to an example? If you’re using Emulator just ignore bugs you founding. I always deploy as RPM on the phone. Sent from Windows Mail It's really not good for mailing lists. I spend more time formatting the reply than actually replying :P It still does nothing. And anyways when being in ApplicationWindow context it shouldn't be necessary? On Friday 12 June 2015 02:20:15 coderusin...@gmail.com wrote: you should call app.activate() -- Med venlig hilsen / Best regards Thomas Tanghus -- Med venlig hilsen / Best regards Thomas Tanghus___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
Thanks, that will keep me occupied for a while :D I've never tried programming anything using dbus. On Friday 12 June 2015 12:47:42 coderusin...@gmail.com wrote: check mce dbus. There is should be a method bot unblanking screen. Sadly it only works when the display is on, not when waking up from deep sleep. I wonder if there's a way to activate the display? -- 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
Re: [SailfishDevel] ApplicationWindow.activate() does nothing
you should call app.activate() Sent from Windows Mail From: Thomas Tanghus Sent: Friday, June 12, 2015 4:51 AM To: devel@lists.sailfishos.org Hi The documentation says: activate() Brings the application in full-screen mode to the foreground. But absolutely nothing happens when I call it. Is anybody using it successfully? https://github.com/tanghus/kitchen-timer-qml/blob/master/qml/harbour-kitchentimer.qml#L271 -- Med venlig hilsen / Best regards Thomas Tanghus___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
