Re: [SailfishDevel] Sailfish OS SDK 1506 update available now
I have to say I am very surprised 1.1.6.27 shipped as is, quite a few of us early adopters suffered from deal breaking bugs like WiFi/USB Tethering (and dev mode) stopped working, Silence sound indicator stopped showing... 2015-06-16 16:32 GMT+03:00 Jarkko Lehtoranta jarkko.lehtora...@jolla.com: Hello again, Today (June 16th) at 13:00 UTC we have published new installers and repositories of the Sailfish OS SDK. The installers for this release of the SDK are available at http://www.sailfishos.org. If you have an older beta release of the SDK, you should see an update notification in the SailfishOS IDE. SDK content has been updated to match Jolla Release 1.1.6.27 (Aaslakkajärvi). Please see below for detailed information of the changes. A couple of things you should be aware of: - As before, in this update the build engine, emulator and targets are reinstalled so you will lose all changes you may have made in those - However, if your application packaging is done correctly, rebuilding your projects should reinstall the packages you have been using. - Any customization done to SDK (adding new package repositories, adding custom targets, additional source paths) will be removed during the installation process so make your own backup of those before starting the update. - If you import existing projects made with a previous version of the Sailfish OS SDK, make sure to select the correct kit in the project configuration step. Both ARM and i486 kits are available. - Package repository contents have been updated and consequently using a previous SDK version with these package repositories is not supported. - Supported host platforms can be found from: https://sailfishos.org/develop/sdk-overview/sdk-release-notes/ - For more information, please see the SDK Beta-Qt5 known issues list at: https://sailfishos.org/develop/sdk-overview/sdk-beta-qt5-known-issues/. SDK IDE (Qt Creator): - Added rpmvalidator deploy step - Updated Sailfish Silica help documentation and examples SDK Build engine: - Build targets refreshed to Jolla release 1.1.6.27 level Emulator: - Emulator packages refreshed to Jolla release 1.1.6.27 level If you have any questions, feel free to either send an email to this mailing list: mailto:devel@lists.sailfishos.org, write it up in http://together.jolla.com and tag your issue with 'sdk' or send an e-mail to developer-c...@jolla.com. Happy hacking, Jolla SDK Team ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Deploy by copying binaries issue
On 16.06.2015 13:12, Андрей Кожевников wrote: Specfile is needed for compilation of course. And it used to install any build dependencies your projects may have. ___ 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 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
[SailfishDevel] Lab experiment: running MerSDK as a container
Hello To celebrate the newly released SDK we present some fun experimental science from the Jolla Airship Research Laboratories. As you might guess the following is very much not supported, and might break, maybe even spectacularly. Proceed at your own risk. We have looked into running the Mer build machine in a container rather than in VirtualBox on Linux hosts. The main reason for this is performance improvements due to the following: - a container sees all CPUs on the machine - a container sees all the RAM on the machine - no virtual machine disk access penalty After some experimenting we got this working so you can build working RPMs in a container sdk machine. If you want to try it yourself, here are the instructions. Note that this requires a fairly new Linux installation. As an example Ubuntu versions older than 15/04 do not work. For this we use the vdi image that comes with SailfishOS SDK. First create a subdirectory and cd into it. Then do this to mount the image (use sufficient amount of sudo/su according to taste): cp ~/SailfishOS/mersdk/mer.vdi . mkdir mersdk qemu-nbd -c /dev/nbd0 mer.vdi mount /dev/nbd0p1 mersdk The build engine is set up so that it expects to be running inside VirtualBox. We need to alter it a bit to work standalone. First tell systemd that this directory is a full operating system install: touch mersdk/etc/os-release Then edit the ssh config file to allow password login and use port 22 (obviously you can set it up according to your own taste). nano mersdk/etc/ssh/sshd_config_engine Remove an unneeded vbox dependency: rm mersdk/etc/systemd/system/sshd.service.requires/etc-ssh-authorized_keys.mount That should be it. Now we can start the container: systemd-nspawn -bD mersdk Note that there is a bug in Ubuntu at least where the console becomes unresponsive after a boot. There's a separate bug so that 'machinectl login' does not work. So we need to use ssh: ssh -lnemo 10.0.1.10 (password nemo) su Now you have root login to a running MerSDK instance and you can configure it up to your liking. As an example set a password for the mersdk user or put your public key in authorized_keys. To compile you need to put your code so that the mersdk user can see it. This can be done with scp, a git checkout, bind mounting a directory from outside the container or whatever you prefer. After all that building a package is simple: mb2 -t SailfishOS-armv7hl build (in your source root as user mersdk) When you are done, log out and shutdown the container: machinectl poweroff mersdk Do try it out and let us know if it a) works and b) makes things better for you. Just remember that if it breaks, you get to keep both pieces. :) Thanks and enjoy, ___ 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] next community meeting 25.6.
Hello, Still no topic proposals, so moving meeting again to 25.6. A great midsummer to all! Carol. On 06/10/2015 10:32 AM, Carol Chen wrote: Hi all, No agenda proposals for tomorrows meeting, moving it one week to 18.6. Please add your topics here: https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/ Thanks, Carol. On 05/21/2015 06:39 PM, Iekku Pylkka wrote: Hi, Thanks to everyone who attended today's meeting. Minutes/logs: Minutes: _http://merproject.org/meetings/mer-meeting/2015/mer-meeting.2015-05-21-14.30.html_ Minutes (text): _http://merproject.org/meetings/mer-meeting/2015/mer-meeting.2015-05-21-14.30.txt_ Log: _http://merproject.org/meetings/mer-meeting/2015/mer-meeting.2015-05-21-14.30.log.html_ Next meeting will be on 2015-06-11 @ 14:30 UTC. Meeting Chair will be Carol Chen (cybette). Please propose discussion topics at: https://together.jolla.com/question/54157/sailfishos-open-source-collaboration-meeting-planning/ Please, add your topic in the post itself, not as a answer. If you propose a topic, it is expected that you show up and present it, or have a substitute participate in the meeting. It is important that you're present at the meeting to guide the discussions in the direction you want, so we do not spend time guessing what kind of info/answers you may be looking for. NOTE: Propose your topic by Tuesday 9.6. Any topics added after that will be considered for the following meeting. Carol will send out meeting invite with confirmed agenda before the meeting. Cheers, Iekku. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org -- Carol cybette Chen Community Chief @ Jolla http://jolla.com +358403502527 @ SMS,PSTN,WeChat cybette @ FreenodeIRC,Twitter,Weibo,LinkedIn,Skype ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
[SailfishDevel] compile error
Hi All, I have to reinstall the sdk and develop tools on my Mac for Jolla. Now after installing and try compile i got this error: I have been look and search google about this error but i can not found any solution any idea's ? Thanks! rote: /home/mersdk/share/SailfishOS/projects/budgetmanager/RPMS/budgetmanager-1.0-1.armv7hl.rpm Wrote: /home/mersdk/share/SailfishOS/projects/budgetmanager/RPMS/budgetmanager-debugsource-1.0-1.armv7hl.rpm Wrote: /home/mersdk/share/SailfishOS/projects/budgetmanager/RPMS/budgetmanager-debuginfo-1.0-1.armv7hl.rpm sending incremental file list budgetmanager-1.0-1.armv7hl.rpm sent 37,490 bytes received 35 bytes 25,016.67 bytes/sec total size is 37,365 speedup is 1.00 Error: /home/nemo/RPMS/budgetmanager-1.0-1.armv7hl.rpm has wrong architecture: armv7hl Finished transaction (status=2, runtime=162ms) Deploy failed 10:51:51: The process /Users/ruditimmermans/.config/SailfishBeta3/mer-sdk-tools/MerSDK/SailfishOS-armv7hl/deploy exited with code 1. Error while building/deploying project budgetmanager (kit: MerSDK-SailfishOS-armv7hl) -- --- Best regards! Rudi Timmermans. ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Deploy by copying binaries issue
On Mon, 2015-06-15 at 11:28 +0300, Jussi Pakkanen wrote: On 12.06.2015 21:38, Timur Kristóf wrote: The sample project has a spec file, and it doesn't fail. If I delete the spec and yaml files from the sample project, I get the same error as I get with my own application. Note: I believe that deploy by copying binaries should work without a spec or yaml file. The build machinery needs the rpm specification to do some things behind the scenes. Thus currently you need a spec or a yaml file even if you deploy by copying binaries. What exactly does it need the .spec / .yaml file for? ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Deploy by copying binaries issue
Specfile is needed for compilation of course. 2015-06-16 13:56 GMT+05:00 Timur Kristóf timur.kris...@gmail.com: On Mon, 2015-06-15 at 11:28 +0300, Jussi Pakkanen wrote: On 12.06.2015 21:38, Timur Kristóf wrote: The sample project has a spec file, and it doesn't fail. If I delete the spec and yaml files from the sample project, I get the same error as I get with my own application. Note: I believe that deploy by copying binaries should work without a spec or yaml file. The build machinery needs the rpm specification to do some things behind the scenes. Thus currently you need a spec or a yaml file even if you deploy by copying binaries. What exactly does it need the .spec / .yaml file for? ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
