Re: [SailfishDevel] Harbour news
Hi, On 18.12.2013 10:32, dcali...@free.fr wrote: Hello, Selon Iekku Pylkka iekku.pyl...@jolla.com: 5) New APIs are approved as we go along - we'll inform you when you're allowed to use new APIs in Harbour apps on the mailing list. If you think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. The current list of approved APIs can be found While I'm requesting for low-level libs, may I suggest two others : - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). as mentioned in several places before. Harbour QA started on 07. Jan 2015 to accept submissions which depend on: libxml2.so.2 - gconf. I allows to access gconf keys. It was the prefered way to store application preferences in the Maemo days, so many codes are using it. As for the Glib stuff, it has a stable API and is available already in Mer. GConf is deprecated upstream and got replaced with DConf in Update 7. See Saapunki 1.0.7.16 release notes[0]. Note: The GConf functions in mlite5 still work, and they transparently use DConf as backend now. [0] https://together.jolla.com/question/45064/release-notes-software-version-10716-saapunki/ br Reto What's your point of view on these two ? Damien. ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Harbour news
Hi, On 18.12.2013 10:32, dcali...@free.fr wrote: Hello, Selon Iekku Pylkka iekku.pyl...@jolla.com: 5) New APIs are approved as we go along - we'll inform you when you're allowed to use new APIs in Harbour apps on the mailing list. If you think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. The current list of approved APIs can be found While I'm requesting for low-level libs, may I suggest two others : - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). as mentioned in several places before. Harbour QA started on 07. Jan 2015 to accept submissions which depend on: libxml2.so.2 - gconf. I allows to access gconf keys. It was the prefered way to store application preferences in the Maemo days, so many codes are using it. As for the Glib stuff, it has a stable API and is available already in Mer. GConf is deprecated upstream and got replaced with DConf in Update 7. See Saapunki 1.0.7.16 release notes[0]. Note: The GConf functions in mlite5 still work, and they transparently use DConf as backend now. [0] https://together.jolla.com/question/45064/release-notes-software-version-10716-saapunki/ br Reto What's your point of view on these two ? Damien. ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
Re: [SailfishDevel] Harbour news
2013/12/19 Matt Austin m...@mattaustin.me.uk: On 18 December 2013 22:33, Thomas Perl th.p...@gmail.com wrote: 2013/12/18 dcali...@free.fr: - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). I've added it to the list of libs to be considered. Let's see... Do you think it likely that some python libraries are likely to be considered too? At the moment, I think the best way is to ship any additional Python libraries you need with your app (install somewhere below /usr/share/$APPNAME/). I think it's much work to start pulling in Python libraries into the repositories and difficult to maintain them there. Because of the dynamic nature of Python, it's even harder to verify apps don't break with OS/library updates compared to native C/C++ libraries (where one could at least do a static check for exported symbols, etc..). Just providing the standard library as shipped with Python 3 is relatively easy to maintain, and apps can then ship different versions of modules they need. We can of course provide some guidelines for how to best package/bundle Python libraries (especially more complicated ones that involve C extension modules) into an application's RPM package, and make sure the bundling/packaging experience is as good as possible. HTH :) Thomas ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
On 24 December 2013 06:15, Thomas Perl th.p...@gmail.com wrote: Because of the dynamic nature of Python, it's even harder to verify apps don't break with OS/library updates compared to native C/C++ libraries (where one could at least do a static check for exported symbols, etc..). Just providing the standard library as shipped with Python 3 is relatively easy to maintain, and apps can then ship different versions of modules they need. Hi Thomas. This is understandable - having Python available at all is fantastic. We can of course provide some guidelines for how to best package/bundle Python libraries (especially more complicated ones that involve C extension modules) into an application's RPM package, and make sure the bundling/packaging experience is as good as possible. Any guides would be very welcome, as I come from a python and web development background. Packaging is something I don't have much experience at. I've started making some general Sailfish Python Development notes on the Mer wiki: https://wiki.merproject.org/wiki/Sailfish/Python_Development Thanks again! Matt. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Ahoy, short update. On 17.12.2013 17:43, Iekku Pylkka wrote: 4) Heads up: Soon we won't allow any files not needing the execution bit set, to have it set. So .png, .desktop and .qml files (and any other file you package with your rpm, except the binary) are not allowed to have permission 755, just 644! You might now get with your rejection info some warning about that, e.g. WARNING [/usr/share/$NAME/qml/pages/main.qml] File must not be executable This is not yet the reason that your rpm got rejected! Just an info that you might need to change something in future. Details will follow. 5) New APIs are approved as we go along - we'll inform you when you're allowed to use new APIs in Harbour apps on the mailing list. If you think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. The current list of approved APIs can be found on https://harbour.jolla.com/faq We allow now some more libraries, please check out: https://harbour.jolla.com/faq Happy hacking Reto ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
I might be wrong, but in principle you can already submit Python apps to Harbour. As long as you manage to package all the needed libraries into your app package. I don't think there is a single public example of it by now, but it should be possible. /Artem. On Thu, Dec 19, 2013 at 6:25 PM, Boris Pohler bo...@pohlers-web.de wrote: Am Donnerstag, den 19.12.2013, 09:58 +0800 schrieb Matt Austin: Hi Thomas, On 18 December 2013 22:33, Thomas Perl th.p...@gmail.com wrote: 2013/12/18 dcali...@free.fr: - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). I've added it to the list of libs to be considered. Let's see... Do you think it likely that some python libraries are likely to be considered too? I'd like to request python-lxml. I tend to use python-lxml quite a bit in my projects, but this isn't easily bundled along with a pure-python project, as it builds against liblxml2 and libxslt. +1, I use lxml a lot, too. btw, is there any time frame, if and when applications based on python e.g. pyotherside will be accepted in the store? Holidays are near and I'll have some time to code ;) If not then I guess I'd either have to bundle a built version with my app (no idea where to begin in doing this though), or switch to a pure-python html/xml parser. Thanks! Matt ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list -- Artem Marchenko http://agilesoftwaredevelopment.com http://twitter.com/AgileArtem ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hello, Selon Alessandro Portale alessan...@casaportale.de: Hi, I am not familiar with the Cairo API. But Qt's pendant (code named Arthur) should offer about the same functionality. It should be available in the Qt C++ API and be supported in SailfishOS. See the QPainter documentation: http://qt-project.org/doc/qt-5/qpainter.html You're right. My point was not to oppose this and that library. Discovering Qt world with Sailfish, while coming from a GLib/Cairo/Gtk one, I would say that I feel quite at home with Qt. It is pleasant to develop with both in fact (thanks Qt for running the Glib loop events for free). My point about bringing Glib/Cairo to harbour (already in Mer, thus Sailfish) was that, as someone here pointed out already, it allows to reuse code already written and just add a new UI (Silica QML) to it. I would say also that in my opinion, it is better to do this than restart from scratch since already in use code may have less bug than a newly written one, since it has been more tested already. So been able to use other low-level libraries than Qt would be good for the Sailfish ecosystem. Of course, for the UI part, one would stick to silica. Have a nice day, Damien. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hello, Selon Iekku Pylkka iekku.pyl...@jolla.com: 5) New APIs are approved as we go along - we'll inform you when you're allowed to use new APIs in Harbour apps on the mailing list. If you think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. The current list of approved APIs can be found While I'm requesting for low-level libs, may I suggest two others : - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). - gconf. I allows to access gconf keys. It was the prefered way to store application preferences in the Maemo days, so many codes are using it. As for the Glib stuff, it has a stable API and is available already in Mer. What's your point of view on these two ? Damien. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hi, my question is similar, but not library-related. What about stock icons (those from /usr/share/theme/jolla-ambient/icons/ that you can use with image://theme/ URIs) ? I'm developing an app that for the Sailfish look feel would like to make heavy use of them. Are there restrictions? For now I'm only using icons coming from the jolla-ambient package. Is this fine, or am I required to ship my app completely with all icons, which would look out-of-place if the user changes the icon theme, though. Martin ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hi all; on our end transfer-engine library addition would be great :) Best, tk On Wed, Dec 18, 2013 at 12:24 PM, Martin Grimme martin.gri...@gmail.comwrote: Hi, my question is similar, but not library-related. What about stock icons (those from /usr/share/theme/jolla-ambient/icons/ that you can use with image://theme/ URIs) ? I'm developing an app that for the Sailfish look feel would like to make heavy use of them. Are there restrictions? For now I'm only using icons coming from the jolla-ambient package. Is this fine, or am I required to ship my app completely with all icons, which would look out-of-place if the user changes the icon theme, though. Martin ___ SailfishOS.org Devel mailing list ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hi again, 2013/12/18 dcali...@free.fr: - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). I've added it to the list of libs to be considered. Let's see... - gconf. I allows to access gconf keys. It was the prefered way to store application preferences in the Maemo days, so many codes are using it. As for the Glib stuff, it has a stable API and is available already in Mer. As the Wikipedia page[1] says: It is in the process of being deprecated as part of the Gnome 3 transition. Migration to its replacement, GSettings and dconf, is ongoing. The replacement is probably going to be dconf instead of GSettings, but let's keep this open for now. If you are using Qt, you can just use QSettings and should be good to go. What we probably will have at some point is restrictions/guidelines/best practices for the storage location of settings. Some apps hardcode /home/nemo/ (or a subdirectory below), which is bad and will probably be disallowed in the future (that doesn't mean you can't write there, just that you shouldn't assume that the username is nemo or that you can write anywhere). We're in the process of figuring out the best way of solving this, if you are a Qt application developer, use QStandardPaths[2] to be on the safe side - if and when the new rules/best practices are in effect, QStandardPaths will do the right thing (if it doesn't do that already). For non-Qt users we'll either have documentation on how to determine the storage paths or a small lib/code snippet that does so, and we'll probably use XDG Basedir Specs + some additions for Harbour apps. This is still not set in stone, so ignore that for now, but be prepare to stop hardcoding /home/nemo/, and start using QStandardPaths/QSettings (or write your code in such a way that the base directory for settings is easy to change later on). 2013/12/18 Martin Grimme martin.gri...@gmail.com: What about stock icons (those from /usr/share/theme/jolla-ambient/icons/ that you can use with image://theme/ URIs) ? I'm developing an app that for the Sailfish look feel would like to make heavy use of them. There are no checks so far for this, it's probably a good idea to use image://theme/ as the way to retrieve this icons, as this might allow us to scan packages in the future and determine which icons are used. The worst thing that could happen in this case is that the icons are missing, which - while still bad - is not as bad as an application not starting up because of missing libs/symbols or crashing because of changed ABI. 2013/12/18 Tone Kastlunger users.giulie...@gmail.com: on our end transfer-engine library addition would be great :) I've added this to the list of libs to be considered. Let's see.. HTH :) Thomas [1] http://en.wikipedia.org/wiki/GConf [2] http://qt-project.org/doc/qt-5.0/qtcore/qstandardpaths.html ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hi Thomas, On 18 December 2013 22:33, Thomas Perl th.p...@gmail.com wrote: 2013/12/18 dcali...@free.fr: - libxml2. As far as I know, their API is quite stable now even if it was not the case in the past (I remember having some trouble with it in 2003, but it's history now !). I've added it to the list of libs to be considered. Let's see... Do you think it likely that some python libraries are likely to be considered too? I'd like to request python-lxml. I tend to use python-lxml quite a bit in my projects, but this isn't easily bundled along with a pure-python project, as it builds against liblxml2 and libxslt. If not then I guess I'd either have to bundle a built version with my app (no idea where to begin in doing this though), or switch to a pure-python html/xml parser. Thanks! Matt ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
On 17/12/13 19:01, Damien Caliste wrote: think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. I posted before about the Glib stack with Cairo, that propose a stable API, that may help to port applications to Sailfish. Namely, glib-2.0, gobject-2.0 and cairo-1.0, plus some other low-level libraries, like libsoup, libcurl or libjpeg-turbo. I know they are low level and Qt provides abstractions for them, but when porting, it's easier to keep these low level libraries, which have a stable API anyway. QML is used for UI on Sailfish in that case with these low level backends (already available in Mer). What do you think ? I support this, at least for Glib/Gobject. Glib is a useful library and, for any app which uses it at all, it will be likely to be completely embedded throughout the code. While the GUI of such an app will need to be reworked for Sailfish, the 80% of the code which actually does something might be able to be left relatively untouched. Graham ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
17.12.2013 21:08, Graham Cobb: On 17/12/13 19:01, Damien Caliste wrote: think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. I posted before about the Glib stack with Cairo, that propose a stable API, that may help to port applications to Sailfish. Namely, glib-2.0, gobject-2.0 and cairo-1.0, plus some other low-level libraries, like libsoup, libcurl or libjpeg-turbo. I know they are low level and Qt provides abstractions for them, but when porting, it's easier to keep these low level libraries, which have a stable API anyway. QML is used for UI on Sailfish in that case with these low level backends (already available in Mer). What do you think ? I support this, at least for Glib/Gobject. Glib is a useful library and, for any app which uses it at all, it will be likely to be completely embedded throughout the code. While the GUI of such an app will need to be reworked for Sailfish, the 80% of the code which actually does something might be able to be left relatively untouched. Graham ___ SailfishOS.org Devel mailing list I'm also all for this! :) I'll specifically point out that Cairo is a very nice vector drawing library and should be included. While there is the QtQuick 2.0 Canvas API, it seems to be GUI-only, without support for file output, which might be something many applications would like to do when doing simple image manipulation. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. I posted before about the Glib stack with Cairo, that propose a stable API, that may help to port applications to Sailfish. Namely, glib-2.0, gobject-2.0 and cairo-1.0, plus some other low-level libraries, like libsoup, libcurl or libjpeg-turbo. I know they are low level and Qt provides abstractions for them, but when porting, it's easier to keep these low level libraries, which have a stable API anyway. QML is used for UI on Sailfish in that case with these low level backends (already available in Mer). What do you think ? All the best, Damien. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Guys, Harbour states that we can actually ship whichever libraries you want together with the apps as long as we follow the specific rules (that are beyond my skills). Could somebody skilled (maybe Jolla sailors themselves?) create an example of using some standard Qt module such as QtGraphicalEffects? And maybe some non-Qt lib too. You know, many packages already exist in Mer repositories, so probably we don't even need to compile anything, just wrap the binaries correctly. Then a list of libraries supported by Harbour will be not an issue completely. Supported - fine, smaller app size; not supported - okay, we ship module together with the app. Best regards. Artem. On Tue, Dec 17, 2013 at 10:36 PM, Martin Kolman martin.kol...@gmail.comwrote: 17.12.2013 21:08, Graham Cobb: On 17/12/13 19:01, Damien Caliste wrote: think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. I posted before about the Glib stack with Cairo, that propose a stable API, that may help to port applications to Sailfish. Namely, glib-2.0, gobject-2.0 and cairo-1.0, plus some other low-level libraries, like libsoup, libcurl or libjpeg-turbo. I know they are low level and Qt provides abstractions for them, but when porting, it's easier to keep these low level libraries, which have a stable API anyway. QML is used for UI on Sailfish in that case with these low level backends (already available in Mer). What do you think ? I support this, at least for Glib/Gobject. Glib is a useful library and, for any app which uses it at all, it will be likely to be completely embedded throughout the code. While the GUI of such an app will need to be reworked for Sailfish, the 80% of the code which actually does something might be able to be left relatively untouched. Graham ___ SailfishOS.org Devel mailing list I'm also all for this! :) I'll specifically point out that Cairo is a very nice vector drawing library and should be included. While there is the QtQuick 2.0 Canvas API, it seems to be GUI-only, without support for file output, which might be something many applications would like to do when doing simple image manipulation. ___ SailfishOS.org Devel mailing list -- Artem Marchenko http://agilesoftwaredevelopment.com http://twitter.com/AgileArtem ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
On Tue, Dec 17, 2013 at 9:36 PM, Martin Kolman martin.kol...@gmail.com wrote: I'll specifically point out that Cairo is a very nice vector drawing library and should be included. While there is the QtQuick 2.0 Canvas API, it seems to be GUI-only, without support for file output, which might be something many applications would like to do when doing simple image manipulation. Hi, I am not familiar with the Cairo API. But Qt's pendant (code named Arthur) should offer about the same functionality. It should be available in the Qt C++ API and be supported in SailfishOS. See the QPainter documentation: http://qt-project.org/doc/qt-5/qpainter.html Also for the the image IO: http://qt-project.org/doc/qt-5/qimage.html#reading-and-writing-image-files Note that these two areas of Qt are not part of the blacklisted QtWidgets, but rather part of QtGui. ___ SailfishOS.org Devel mailing list
Re: [SailfishDevel] Harbour news
Hi, 2013/12/17 Damien Caliste dcali...@free.fr: think you need an API (library or QML import) for your Harbour app that is not yet approved, let us know on sailfish-devel. I posted before about the Glib stack with Cairo, that propose a stable API, that may help to port applications to Sailfish. Namely, glib-2.0, gobject-2.0 and cairo-1.0, plus some other low-level libraries, like libsoup, libcurl or libjpeg-turbo. I know they are low level and Qt provides abstractions for them, but when porting, it's easier to keep these low level libraries, which have a stable API anyway. QML is used for UI on Sailfish in that case with these low level backends (already available in Mer). What do you think ? glib-2.0 is going to be allowed soon. gobject-2.0 very likely also. For the others, I've added them to the list of libraries/APIs we'll review and think about adding. Where features overlap (e.g. libcurl + libsoup), we'll probably pick only one of them. In that specific case, we'll probably pick libcurl, as it has a good, controlled history of ABI stability / proper soversioning: http://curl.haxx.se/libcurl/abi.html - libsoup on the other hand has changed API in major ways between 2.2 and 2.4, for example: https://developer.gnome.org/libsoup/2.32/libsoup-porting-2.2-2.4.html As Artem mentioned in a later post to this thread, if you really really want to have a library and it's not supported, you can always include it as shared library (or link it statically if the license allows) in your app. See https://harbour.jolla.com/faq for where you should put these libs. HTH :) Thomas ___ SailfishOS.org Devel mailing list
