Re: [SailfishDevel] SDK and Harbour news
On Fri, 2013-11-22 at 17:21 +0200, Mohammed Hassan wrote: GStreamer is not a supported store API for now. I am sure this will What does that mean ? I can't submit any apps that use gstreamer to the Harbour ? change soon especially after we transition to GStreamer 1.x (Currently all our media stack is using GStreamer 0.10). May I ask you what codecs you would like to see? I'd like to port over these two http://store.ovi.com/content/267364 and http://store.ovi.com/content/263944 And I'm also working on a gstelement to use the more correct (and updated) sidfp library for SID playback. -- Kaj-Michael Lang mil...@tal.org ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
On Fri, 22 Nov 2013 08:38:17 +0200 Kaj-Michael Lang mil...@tal.org wrote: On Thu, 2013-11-21 at 12:20 +, Iekku Pylkka wrote: Shared libraries ·You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. What about possible extension apps ? Say gstreamer element/tracker extractor that extends the system media player to support more codecs/formats ? (Me hoping that that is possible, as it was on the N900 and N9) GStreamer is not a supported store API for now. I am sure this will change soon especially after we transition to GStreamer 1.x (Currently all our media stack is using GStreamer 0.10). May I ask you what codecs you would like to see? Cheers, ___ SailfishOS.org Devel mailing list
[SailfishDevel] SDK and Harbour news
Ahoy all, As you might have noticed, there has been lot of stuff happening on application development and application releasing. Some of you who have already submitted applications to Harbour (Jolla's app store intake) have faced these challenges already. Thank you very much for your submissions. Here is a list of items we have identified that cause headache and are the reasons why your app might not have gotten store approval yet: - Icon size: * SDK still uses 90x90 icon size whereas the device uses 86x86. Harbour submission requires 86x86 icons. An update to the SDK will be released soon to sync it up to the new icon size. - Icon path defined in .desktop file: * Application icon path is not needed anymore (Icon=appname is enough), you will have to remove absolute paths for Harbour submission. The home screen in upcoming SDK release will have a fix for this. - Application name * There will be a FAQ on Harbour regarding what file names need to match the RPM package name at upload time. Your application name should be in dotted form, e.g. com.example.myapp and we will soon update Harbour to validate this and then all the applications should follow this naming convention. - QML API * For QML application development we support QtQuick 2.x and Sailfish Silica 1.0. In our repositories there are various other packages but as they are not reviewed by us we cannot guarantee that APIs they provide are available in future, so take caution when using them - your application might be rejected or stop working if you are using unsupported API. - Shared libraries * You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. - Private QML imports * If you are using custom QML imports, you have to install them into /usr/share/name of your app/, you are not allowed to install the QML imports anywhere else. Also, the name of your QML import must match the application package name (e.g. an application org.example.coolapp can only have a single private qml import module, and that must be imported as import org.example.coolapp 1.0). - Runtimes * Application runtimes such as Python are not supported yet, but we are actively working on getting Python support into shape, at which point Python QML APIs will be allowed in Harbour. Stay tuned. - More info * There will be the mentioned FAQ page on Harbour which addresses the known application submission problems. Hopefully, most of these will make sense and not require clarification but if you need any help at all, just holler. We hope to expand the list of supported APIs, and are interested in feedback from you as to what you would like to see and be able to do in store applications. Should you have any questions or improvement ideas of these, please send replies to this mailing list. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
Hi, On 21.11.2013 15:24, Putze Sven wrote: On 21.11.2013, at 14:06, Reto Zingg reto.zi...@jolla.com wrote: On 21.11.2013 14:53, Putze Sven wrote: - Shared libraries · You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. Hi, do I get it right that for each and every App there will be a directory in the form /usr/share/mydomain.mygreatcompany.nameofmyapp the folder just exists if the rpm creates it. which is private and for App access only? IMHO you could/should create a directory standard which should be followed inside this folder. E.g. like the bundle folders in the Apple universe. No, the folder is not private and any app can access it's content. And no, do not write into the folder at runtime. With 'your own private copies of ...' we mean: your version of a shared library, which we don't want to have installed any where else in the system (which it might interfere with other apps) and shall just be used by this very one app. Sorry, my wording was not precise enough. I meant private in a way that this folder can contain anything that an app needs to run and I want to deliver upon installation. Like, e.g. libraries, images, all kind of resource files, maybe even database templates. I didn't understand it as a runtime work path. I am just picking on this because some mails in this list weren't clear or contradictory. Yes, that is what we mean :-) You can have under '/usr/share/mydomain.mygreatcompany.nameofmyapp' what ever you want/need for your app to run. br Reto Best. Sven ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
Hi, On 21.11.2013 15:58, Andrey Kozhevnikov wrote: i have two binaries in application, how to? can you elaborate more? Why would you have to apps in one rpm? br Reto On 21.11.2013 19:52, Reto Zingg wrote: Hi, On 21.11.2013 15:48, Andrey Kozhevnikov wrote: binary names rename same or should be renamed in domain-style too? /usr/bin/myapp or /usr/bin/org.coderus.myapp ? yes, also the binary name has to be named after that schema. But do not mix that up with the Title you give your application in Harbour where you upload the application. br Reto On 21.11.2013 18:20, Iekku Pylkka wrote: Ahoy all, As you might have noticed, there has been lot of stuff happening on application development and application releasing. Some of you who have already submitted applications to Harbour (Jolla's app store intake) have faced these challenges already. Thank you very much for your submissions. Here is a list of items we have identified that cause headache and are the reasons why your app might not have gotten store approval yet: - Icon size: ·SDK still uses 90x90 icon size whereas the device uses 86x86. Harbour submission requires 86x86 icons. An update to the SDK will be released soon to sync it up to the new icon size. - Icon path defined in .desktop file: ·Application icon path is not needed anymore (Icon=appname is enough), you will have to remove absolute paths for Harbour submission. The home screen in upcoming SDK release will have a fix for this. - Application name ·There will be a FAQ on Harbour regarding what file names need to match the RPM package name at upload time. Your application name should be in dotted form, e.g. com.example.myapp and we will soon update Harbour to validate this and then all the applications should follow this naming convention. - QML API ·For QML application development we support QtQuick 2.x and Sailfish Silica 1.0. In our repositories there are various other packages but as they are not reviewed by us we cannot guarantee that APIs they provide are available in future, so take caution when using them - your application might be rejected or stop working if you are using unsupported API. - Shared libraries ·You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. - Private QML imports ·If you are using custom QML imports, you have to install them into /usr/share/name of your app/, you are not allowed to install the QML imports anywhere else. Also, the name of your QML import must match the application package name (e.g. an application org.example.coolapp can only have a single private qml import module, and that must be imported as import org.example.coolapp 1.0). - Runtimes ·Application runtimes such as Python are not supported yet, but we are actively working on getting Python support into shape, at which point Python QML APIs will be allowed in Harbour. Stay tuned. - More info ·There will be the mentioned FAQ page on Harbour which addresses the known application submission problems. Hopefully, most of these will make sense and not require clarification but if you need any help at all, just holler. We hope to expand the list of supported APIs, and are interested in feedback from you as to what you would like to see and be able to do in store applications. Should you have any questions or improvement ideas of these, please send replies to this mailing list. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
Hi, On 21.11.2013 15:48, Andrey Kozhevnikov wrote: binary names rename same or should be renamed in domain-style too? /usr/bin/myapp or /usr/bin/org.coderus.myapp ? yes, also the binary name has to be named after that schema. But do not mix that up with the Title you give your application in Harbour where you upload the application. br Reto On 21.11.2013 18:20, Iekku Pylkka wrote: Ahoy all, As you might have noticed, there has been lot of stuff happening on application development and application releasing. Some of you who have already submitted applications to Harbour (Jolla's app store intake) have faced these challenges already. Thank you very much for your submissions. Here is a list of items we have identified that cause headache and are the reasons why your app might not have gotten store approval yet: - Icon size: ·SDK still uses 90x90 icon size whereas the device uses 86x86. Harbour submission requires 86x86 icons. An update to the SDK will be released soon to sync it up to the new icon size. - Icon path defined in .desktop file: ·Application icon path is not needed anymore (Icon=appname is enough), you will have to remove absolute paths for Harbour submission. The home screen in upcoming SDK release will have a fix for this. - Application name ·There will be a FAQ on Harbour regarding what file names need to match the RPM package name at upload time. Your application name should be in dotted form, e.g. com.example.myapp and we will soon update Harbour to validate this and then all the applications should follow this naming convention. - QML API ·For QML application development we support QtQuick 2.x and Sailfish Silica 1.0. In our repositories there are various other packages but as they are not reviewed by us we cannot guarantee that APIs they provide are available in future, so take caution when using them - your application might be rejected or stop working if you are using unsupported API. - Shared libraries ·You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. - Private QML imports ·If you are using custom QML imports, you have to install them into /usr/share/name of your app/, you are not allowed to install the QML imports anywhere else. Also, the name of your QML import must match the application package name (e.g. an application org.example.coolapp can only have a single private qml import module, and that must be imported as import org.example.coolapp 1.0). - Runtimes ·Application runtimes such as Python are not supported yet, but we are actively working on getting Python support into shape, at which point Python QML APIs will be allowed in Harbour. Stay tuned. - More info ·There will be the mentioned FAQ page on Harbour which addresses the known application submission problems. Hopefully, most of these will make sense and not require clarification but if you need any help at all, just holler. We hope to expand the list of supported APIs, and are interested in feedback from you as to what you would like to see and be able to do in store applications. Should you have any questions or improvement ideas of these, please send replies to this mailing list. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
i have two binaries in application, how to? On 21.11.2013 19:52, Reto Zingg wrote: Hi, On 21.11.2013 15:48, Andrey Kozhevnikov wrote: binary names rename same or should be renamed in domain-style too? /usr/bin/myapp or /usr/bin/org.coderus.myapp ? yes, also the binary name has to be named after that schema. But do not mix that up with the Title you give your application in Harbour where you upload the application. br Reto On 21.11.2013 18:20, Iekku Pylkka wrote: Ahoy all, As you might have noticed, there has been lot of stuff happening on application development and application releasing. Some of you who have already submitted applications to Harbour (Jolla's app store intake) have faced these challenges already. Thank you very much for your submissions. Here is a list of items we have identified that cause headache and are the reasons why your app might not have gotten store approval yet: - Icon size: ·SDK still uses 90x90 icon size whereas the device uses 86x86. Harbour submission requires 86x86 icons. An update to the SDK will be released soon to sync it up to the new icon size. - Icon path defined in .desktop file: ·Application icon path is not needed anymore (Icon=appname is enough), you will have to remove absolute paths for Harbour submission. The home screen in upcoming SDK release will have a fix for this. - Application name ·There will be a FAQ on Harbour regarding what file names need to match the RPM package name at upload time. Your application name should be in dotted form, e.g. com.example.myapp and we will soon update Harbour to validate this and then all the applications should follow this naming convention. - QML API ·For QML application development we support QtQuick 2.x and Sailfish Silica 1.0. In our repositories there are various other packages but as they are not reviewed by us we cannot guarantee that APIs they provide are available in future, so take caution when using them - your application might be rejected or stop working if you are using unsupported API. - Shared libraries ·You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. - Private QML imports ·If you are using custom QML imports, you have to install them into /usr/share/name of your app/, you are not allowed to install the QML imports anywhere else. Also, the name of your QML import must match the application package name (e.g. an application org.example.coolapp can only have a single private qml import module, and that must be imported as import org.example.coolapp 1.0). - Runtimes ·Application runtimes such as Python are not supported yet, but we are actively working on getting Python support into shape, at which point Python QML APIs will be allowed in Harbour. Stay tuned. - More info ·There will be the mentioned FAQ page on Harbour which addresses the known application submission problems. Hopefully, most of these will make sense and not require clarification but if you need any help at all, just holler. We hope to expand the list of supported APIs, and are interested in feedback from you as to what you would like to see and be able to do in store applications. Should you have any questions or improvement ideas of these, please send replies to this mailing list. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
- Shared libraries · You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. Hi, do I get it right that for each and every App there will be a directory in the form /usr/share/mydomain.mygreatcompany.nameofmyapp which is private and for App access only? IMHO you could/should create a directory standard which should be followed inside this folder. E.g. like the bundle folders in the Apple universe. Best. Sven ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
Thanks for the update, Lekku Questions there are :) **Submitted apps (and to be submitted ones)** First of all what do we do with the apps already approved, under QA or scheduled for submission tomorrow? You know, launch date is a very special date, I wouldn't like to change anything unless absolutely necessary. Will the apps violating these rules, but currently approved or submitted and under QA still work fine for the launch? And will users get proper update notifications when you change package name from e.g. flashlight to com.iamcool.flashlight and update icon to 86x86? What about the apps that are to be submitted today-tomorrow? Do you know when this will be a FAQ will happen and since when shall it be enforced (rather than just recommended)? **QML API and Shared libraries** What about standard Qt5 modules such as qt5-qtdeclarative-systeminfo and qt5-qtgraphicaleffects Can I still Require them in .yaml/.spec to guarantee that device will install them or shall we bundle them in manually somehow? Cheers, Artem. On Thu, Nov 21, 2013 at 2:20 PM, Iekku Pylkka iekku.pyl...@jolla.comwrote: Ahoy all, As you might have noticed, there has been lot of stuff happening on application development and application releasing. Some of you who have already submitted applications to Harbour (Jolla's app store intake) have faced these challenges already. Thank you very much for your submissions. Here is a list of items we have identified that cause headache and are the reasons why your app might not have gotten store approval yet: - Icon size: · SDK still uses 90x90 icon size whereas the device uses 86x86. Harbour submission requires 86x86 icons. An update to the SDK will be released soon to sync it up to the new icon size. - Icon path defined in .desktop file: · Application icon path is not needed anymore (Icon=appname is enough), you will have to remove absolute paths for Harbour submission. The home screen in upcoming SDK release will have a fix for this. - Application name · There will be a FAQ on Harbour regarding what file names need to match the RPM package name at upload time. Your application name should be in dotted form, e.g. com.example.myapp and we will soon update Harbour to validate this and then all the applications should follow this naming convention. - QML API · For QML application development we support QtQuick 2.x and Sailfish Silica 1.0. In our repositories there are various other packages but as they are not reviewed by us we cannot guarantee that APIs they provide are available in future, so take caution when using them - your application might be rejected or stop working if you are using unsupported API. - Shared libraries · You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. - Private QML imports · If you are using custom QML imports, you have to install them into /usr/share/name of your app/, you are not allowed to install the QML imports anywhere else. Also, the name of your QML import must match the application package name (e.g. an application org.example.coolapp can only have a single private qml import module, and that must be imported as import org.example.coolapp 1.0). - Runtimes · Application runtimes such as Python are not supported yet, but we are actively working on getting Python support into shape, at which point Python QML APIs will be allowed in Harbour. Stay tuned. - More info · There will be the mentioned FAQ page on Harbour which addresses the known application submission problems. Hopefully, most of these will make sense and not require clarification but if you need any help at all, just holler. We hope to expand the list of supported APIs, and are interested in feedback from you as to what you would like to see and be able to do in store applications. Should you have any questions or improvement ideas of these, please send replies to this mailing list. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list -- Artem Marchenko http://agilesoftwaredevelopment.com http://twitter.com/AgileArtem ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
On 21/11/13 10:50 PM, Robin Burchell wrote: Hi Artem, On Thu, Nov 21, 2013 at 1:41 PM, Artem Marchenko artem.marche...@gmail.com wrote: Thanks for the update, Lekku I, not L :-) Will the apps violating these rules, but currently approved or submitted and under QA still work fine for the launch? And will users get proper update notifications when you change package name from e.g. flashlight to com.iamcool.flashlight and update icon to 86x86? Any update will trigger an update notification in store as far as I know. What about the apps that are to be submitted today-tomorrow? Do you know when this will be a FAQ will happen and since when shall it be enforced (rather than just recommended)? First draft was written yesterday, it might take a little longer while we nail out a few final things. Not too long I'd hope. *QML API and Shared libraries* What about standard Qt5 modules such as qt5-qtdeclarative-systeminfo and qt5-qtgraphicaleffects Can I still Require them in .yaml/.spec to guarantee that device will install them or shall we bundle them in manually somehow? You will still need to specify your requirements. Note: not everything with a Qt in the name is necessarily supported. I'll make sure a full list will come around the same time as the FAQ/with the FAQ. In particular, as I understand it, QtSystemInfo is not yet API/ABI stable upstream (Lorn, please correct me if I'm wrong...), so we are unable to offer support for it at this time. QtSystemInfo is not yet officially released from upstream, not stable and is currently undergoing a change in API. :) Cheers, Artem. BR, Robin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] SDK and Harbour news
Ahoi Sailors; I do believe this info will be available in the wiki as well, correct? Best, tortoisedoc On Thu, Nov 21, 2013 at 2:20 PM, Iekku Pylkka iekku.pyl...@jolla.comwrote: Ahoy all, As you might have noticed, there has been lot of stuff happening on application development and application releasing. Some of you who have already submitted applications to Harbour (Jolla's app store intake) have faced these challenges already. Thank you very much for your submissions. Here is a list of items we have identified that cause headache and are the reasons why your app might not have gotten store approval yet: - Icon size: · SDK still uses 90x90 icon size whereas the device uses 86x86. Harbour submission requires 86x86 icons. An update to the SDK will be released soon to sync it up to the new icon size. - Icon path defined in .desktop file: · Application icon path is not needed anymore (Icon=appname is enough), you will have to remove absolute paths for Harbour submission. The home screen in upcoming SDK release will have a fix for this. - Application name · There will be a FAQ on Harbour regarding what file names need to match the RPM package name at upload time. Your application name should be in dotted form, e.g. com.example.myapp and we will soon update Harbour to validate this and then all the applications should follow this naming convention. - QML API · For QML application development we support QtQuick 2.x and Sailfish Silica 1.0. In our repositories there are various other packages but as they are not reviewed by us we cannot guarantee that APIs they provide are available in future, so take caution when using them - your application might be rejected or stop working if you are using unsupported API. - Shared libraries · You can ship your own private copies of shared libraries that you link against in /usr/share/name of your app/, you are not allowed to install shared libraries anywhere else. - Private QML imports · If you are using custom QML imports, you have to install them into /usr/share/name of your app/, you are not allowed to install the QML imports anywhere else. Also, the name of your QML import must match the application package name (e.g. an application org.example.coolapp can only have a single private qml import module, and that must be imported as import org.example.coolapp 1.0). - Runtimes · Application runtimes such as Python are not supported yet, but we are actively working on getting Python support into shape, at which point Python QML APIs will be allowed in Harbour. Stay tuned. - More info · There will be the mentioned FAQ page on Harbour which addresses the known application submission problems. Hopefully, most of these will make sense and not require clarification but if you need any help at all, just holler. We hope to expand the list of supported APIs, and are interested in feedback from you as to what you would like to see and be able to do in store applications. Should you have any questions or improvement ideas of these, please send replies to this mailing list. Happy hacking, The Jolla Crew ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
