Re: [SailfishDevel] Is running an app with qmlscene fine for harbour?

[Martin Kolman]

On 11/1/19 8:26 PM, szo...@gmail.com wrote:

Just curious as last mention of qmlscene on tjc is from 2014 and modRana at 
that point was supposedly ran with it,


I think that post is mostly about how to use qmlscene during development 
of pure QML or Python + QML apps.



  is it still ok to have .desktop file calling qmlscene or is that a no-no for 
harbour apps even for pure qml apps?


I think you are supposed to use the "sailfish-qml" tool in such a case, see:

https://harbour.jolla.com/faq#.desktop-Files

I think this is really the only way or at least it was when I did 
initially package modRana years ago. I would definitely use qmlscene if 
I could, as sailfish-qml


imposes various more or less brain-dead limitations on your application, 
like where you main qml file need to be located, how it needs to be 
called. It also


does not have a way to directly set QML import path (but thanfully 
respects the corresponding environmental variables) & there are also 
some issues with


argument parsing to an application run with sailfish-qml.


  (asking as modrana currently seems to be calling a binary, so had to go 
through sdk? If not qmlscene what is proper way to submit pure qml apps?)


I basically get fed up with all the hack I had in place due to using 
sailfish-qml and decided writing a simple launcher in C++/Qt5 was 
actually less tedious. :)


Some of the backstory for the decision can be read here:

https://github.com/M4rtinK/modrana/commit/de346537eda664d15da3941d186439c8e06d71c2#diff-d266491a492b352f7a6b4d56e612bc7d

https://github.com/M4rtinK/modrana/blob/master/run/launcher/README.rst

To summarize:

- it is simpler for users to run "modrana" from a terminal than typing 
"sailfish-qml harbour-modrana"


- you can easily support the usual options such as --help, --version a 
others without sailfish-qml getting in the way


- you can easily set all the QML and Python import paths without bending 
backwards like with sailfish-qml


- having a C++/Qt5 launcher opens the possibility to interact with Qt5 
C++ APIs & pure C/C++ APIs not available from QML or via Python and 
exposing them to the QML context as needed


- IIRC having a native launcher makes it possible to use the QML 
profiling and tracing functionality available in QtCreator


- a C++/Qt5 launcher is pretty much mandatory anyway for running modRana 
(or other Qt 5 + Python 3) applications from Flatpak or on Android


Also please note that the native launcher simply adds another way how to 
launch modRana, that is generally more convenient in specific scenarios. 
You can still run modRana via QML scene and even by running modrana.py 
and it should do the right thing. :)


As for using the Sailfish OS/Qt SDK - I did use it for the initial 
development of the launcher & bigger changes, but I generally simply 
build the launcher from the command line on desktop or on Mer OBS for 
Sailfish OS, so the SDK is not strictly needed (though the code 
completion is certainly useful, given my minimal knowledge of C++ :D).


In short I suggest looking into sailfish-qml or possibly feel free to 
repurpose the modRana launcher for your purposes. :) Also IIRC Poor Maps 
has (or at least used to have) a really minimal native launcher for use 
in Flatpaks.



___
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] Boolean dependencies in RPM SPEC

[Martin Kolman]

Sat, 11 May 2019 17:53:27 +0300 Rinigus :
Summary from IRC chat on the topic: David spotted that BuildRequires 
is not mentioned in the list of boolean dependencies (thank you!).


So, next question: which condition could I use in %if expansion of 
SPEC to distinguish SFOS 3.0.3.x from the earlier versions? Maybe 
there is some variable defined at OBS build env that can be used?


I know that Fedora/RHEL/CentOS/OpenSUSE and RPM based distros in general 
usually have some RPM macro[0] defined that can be used to check on 
which "target" the package is being built and then behave accordingly. 
That way people can use the same spec file across multiple Fedora and 
even RHEL releases. I would assume Sailfish OS might have something 
similar and if not it definitely should be added.


But if no such mechanism is available at the moment, there might still 
be a way to share a common spec file the way modRana does it. I didn't 
want to maintain three spec files for modRana (one for Open Repos, one 
for Harbour, one for Fedora) so I've added conditions to the single 
shared spec file based on custom RPM variables. The variables are then 
set at build time based on custom config for the given Mer OBS project.


The condition can be seen for example here:

https://github.com/M4rtinK/modrana/blob/master/packaging/modrana.spec#L33


The custom repo configs can be seen here:

https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana

https://build.merproject.org/project/prjconf/home:MartinK:sailfish:modrana-harbour


Note that the modRana project has just %with_sailfish set while 
modrana-harbour has also %with_harbour set.


I think you could use something similar, eq. %with_old_icu or %sfos_303 
on two separate OBS projects sharing the same spec file


with the respective conditions set.


Best Wishes

Martin Kolman


[0] https://docs.fedoraproject.org/en-US/packaging-guidelines/DistTag/



Rinigus



On Sat, May 11, 2019 at 4:38 PM rinigus <mailto:rinigus@gmail.com>> wrote:


Hi,

the problem is while building at OBS:
https://build.merproject.org/package/show/home:rinigus:maps/mapnik

Rinigus

On Sat, May 11, 2019 at 4:30 PM David Llewellyn-Jones
mailto:da...@flypig.co.uk>> wrote:

On 11/05/2019 16:12, rinigus wrote:
[snip]
> BuildRequires: (libicu52-devel or libicu-devel)
>
> as in
>

https://github.com/rinigus/pkg-mapnik/blob/da5b6a11667b286c89bbee93eb57e2d4d52d5902/rpm/mapnik.spec#L16

[snip]
> Hence the question - how can I add support for 3.0.2.x and
3.0.3.x using
> the same SPEC file? On device, RPM has version 4.14, if its
of any
> importance.

For 'BuildRequires', it's presumably the versioning in your
SDK tooling
which is important, rather than the RPM version on your
device. It may
be worth checking that too.

Or is the problem you're experiencing happening at install
time (i.e. in
relation to the 'Requires' on line 36 of that file)? I can't
see any
difference between your version and the examples in the spec
you posted.

David
-- 
Website: http://www.flypig.co.uk

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
<mailto:devel-unsubscr...@lists.sailfishos.org>


___
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] qt upgrade

[Martin Kolman]

Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg 
:
Flatpak would make our phones so much more insecure - instead of Jolla 
updating bad/insecure libraries (which also happens at a pace that 
leaves to be desired) you become dependent on the devs of the 
application you are using doing that.


I don't think this is correct. Unlike for example App image where 
developers AFAIK *do* have to bundle everything, Flatpak has a concept 
of shared application runtimes.  As long an application uses sensitive 
libraries (mainly crypto related) from the runtime, it's not really 
different from the current system with shared system libraries - as long 
as the runtime is being properly maintained.


Also both main app distribution channels in Sailfish OS are taking 
binary RPMs only and there is nothing really preventing developers from 
bundling about anything already.




Since Jolla tries to have one of its' claims to fame be security it 
seems that flatpak support should be just about the last thing they 
should support.


Looks like the Purism Librem 5 open hardware phone project aims to use 
Flatpaks for third party application distribution:


https://www.phoronix.com/scan.php?page=news_item=Purism-PureOS-Store-Flatpaks



Just my 2c

Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman 
mailto:martin.kol...@gmail.com>>:


Sun, 10 Feb 2019 09:56:06 +0200 Rinigus 
<mailto:rinigus@gmail.com>:

Morning,

suggestion to consider Qt 5.12 in /opt comes from the following:

* newer web engine
* we can use and contribute to the code written for Plasma with
its Kirigami

It will not bring native new applications, we don't have Silica
for it. However, I personally think it makes more sense to use
and help out with the development of Linux-based solutions than
to use Android-provided web browsers through SFOS Android
compatibility layer.

This would not to be intended to be installed in /usr and having
platform supporting multiple Qt versions at once. I have no idea
whether its possible and no desire to get into messing up the
system layer.

Dmitriy: I don't know whether you can mix different Qt versions
in the same application. In this respect, yes, you could probably
ship Qt 512 stack fully, but would probably have to stay away
from the system-provided Qt.

Leszek: fragmentation is to be considered, indeed. But, as far as
I understood, it makes sense to develop browser against the last
version of Qt. In some aspect, using Qt59 on SFOS contributes to
fragmentation in a way that we, on SFOS, will be using the
version that is slowly phased out already. At present, Kirigami
is developed using Qt512, with Qt511 version having at least one
bug that will never be fixed. Not sure whether Kirigami runs
against Qt59. So, if we would like to run Kirigami apps, Qt 5.12
is most probably needed.


I hope eventually support for using Flatpak for package
distribution is added to Sailfish OS, as that would make it
possible to decouple the "system" Qt version from the
"application" Qt version. Updating the system version would not
longer risk breakage in third party applications and could be done
on it's own, likely slower, pace. On the other hand updating the
"application" Qt would mean just releasing a new Flatpak runtime
with the updated Qt version. Old application would continue
working with old runtime/-s while new apps would be able to use
all the new goodies available via the new runtime. IIRC this is
already being done for Qt on the desktop via the Flatpak runtimes
maintained by the KDE project.

Of course there are some trade-offs and things to consider - you
would have to, in some capacity, maintain multiple versions of Qt
and system libraries in parallel. On the other hand, each Qt
version would be either a "system" only one or "application" one.
Not one that needs to be perfect or else both the system and apps
will stop working. This could help to reduce the maintenance
burden somewhat.

Also, even if it would be nice to keep all older runtimes around
so that all old (and likely abandoned) apps continue working, it
would be likely prudent to stop maintaining old runtimes after a
while to keep the maintenance burden reasonable.

There is also a question if this is something that community can
at least start or Jolla involvement is needed. As already
mentioned in the thread, due to Silica still being closed source a
community only Flatpak effort likely could not support running
Silica applications. A Jolla provided runtime - or open source
Silica - would be needed for that.




Cheers,

Rinigus

On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin mailto:dpur...@gmail.com>> wrote:

Hi all,

if there are some parts 

Re: [SailfishDevel] qt upgrade

[Martin Kolman]

Sun, 10 Feb 2019 09:56:06 +0200 Rinigus :

Morning,

suggestion to consider Qt 5.12 in /opt comes from the following:

* newer web engine
* we can use and contribute to the code written for Plasma with its 
Kirigami


It will not bring native new applications, we don't have Silica for 
it. However, I personally think it makes more sense to use and help 
out with the development of Linux-based solutions than to use 
Android-provided web browsers through SFOS Android compatibility layer.


This would not to be intended to be installed in /usr and having 
platform supporting multiple Qt versions at once. I have no idea 
whether its possible and no desire to get into messing up the system 
layer.


Dmitriy: I don't know whether you can mix different Qt versions in the 
same application. In this respect, yes, you could probably ship Qt 512 
stack fully, but would probably have to stay away from the 
system-provided Qt.


Leszek: fragmentation is to be considered, indeed. But, as far as I 
understood, it makes sense to develop browser against the last version 
of Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation 
in a way that we, on SFOS, will be using the version that is slowly 
phased out already. At present, Kirigami is developed using Qt512, 
with Qt511 version having at least one bug that will never be fixed. 
Not sure whether Kirigami runs against Qt59. So, if we would like to 
run Kirigami apps, Qt 5.12 is most probably needed.


I hope eventually support for using Flatpak for package distribution is 
added to Sailfish OS, as that would make it possible to decouple the 
"system" Qt version from the "application" Qt version. Updating the 
system version would not longer risk breakage in third party 
applications and could be done on it's own, likely slower, pace. On the 
other hand updating the "application" Qt would mean just releasing a new 
Flatpak runtime with the updated Qt version. Old application would 
continue working with old runtime/-s while new apps would be able to use 
all the new goodies available via the new runtime. IIRC this is already 
being done for Qt on the desktop via the Flatpak runtimes maintained by 
the KDE project.


Of course there are some trade-offs and things to consider - you would 
have to, in some capacity, maintain multiple versions of Qt and system 
libraries in parallel. On the other hand, each Qt version would be 
either a "system" only one or "application" one. Not one that needs to 
be perfect or else both the system and apps will stop working. This 
could help to reduce the maintenance burden somewhat.


Also, even if it would be nice to keep all older runtimes around so that 
all old (and likely abandoned) apps continue working, it would be likely 
prudent to stop maintaining old runtimes after a while to keep the 
maintenance burden reasonable.


There is also a question if this is something that community can at 
least start or Jolla involvement is needed. As already mentioned in the 
thread, due to Silica still being closed source a community only Flatpak 
effort likely could not support running Silica applications. A Jolla 
provided runtime - or open source Silica - would be needed for that.





Cheers,

Rinigus

On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin > wrote:


Hi all,

if there are some parts of the newer Qt you need in your app, you
can always compile it yourself, link your app against the newer
version and ship these libraries with your app.

Cheers
Dmitriy

On Sat, Feb 9, 2019 at 6:44 PM rinigus mailto:rinigus@gmail.com>> wrote:

Hi,

sounds like there are porting and licensing issues on the way
of getting qt 5.9 for SFOS (see logs from the last
#mer-meeting). Its all understandable, but it would be great
to get a way forward. Not sure whether it has been considered
by others and I wonder whether we can make a separate Qt 5.12
packages for /opt/qt512?

From a quick test, it is possible to run non-silica
applications as well (tested with qmlscene and QML with plain
Window). In that test, even keyboard worked as expected. Look
was non-native, but let it be for now.

So, I wonder, whether its possible to get Qt 5.12 compiled
with /opt/qt512 prefix and then use it for development using
the latest libs (new web browser?) and collaborate with other
mobile Linux'es out there. As far as I remember, Wayland was
rather old and, maybe, it will preclude Qt 5.12 compilation.
@mal, though, had a newer version around and it may serve a
purpose for such project. Is there anything else that should
be considered?

Cheers,

Rinigus

PS: Please consider it as request-for-comment and not as any
kind of statement nor call-for-action :)
___

Re: [SailfishDevel] qt upgrade

[Martin Kolman]

Sun, 10 Feb 2019 12:20:31 +0100 Lukáš Karas :

Hi all


To sum up, no idea how much we can help with 5.9 transition and what's
holding it back specifically.


 From the Fosdem discussion, I feel like there is no big technical issue.
There was message that majority of SFOS core components already has branches
prepared for Qt 5.9. Issue with transition is licensing - more Qt components
was switched from LGPLv2.1 license to LGPLv3 [1]. If I understand it
correctly, LGPLv2 guarantees you as a user that you will get source code for
the library and you should be able to update library without application
modification - it allows proprietary applications to link shared Qt
libraries... But this second right is not mentioned explicitly. It is fixed in
LGPLv3 that guarantee to user that have to be possible to replace libraries.

This is not problem for SFOS itself, when you can get root access just by one
click. But for some Jolla partners, that want to create certified devices for
governments, this right may be a problem. Noone mention specific companies,
but it is clear that Jolla needs approval from their partners first...


I really hope they finally decide to just got with GPLv3, as it's not 
just Qt, but many


important system libraries, that are stuck on ancient pre-GPLv3 
versions. Many of those libraries


are likely no longer maintained by upstream, which long ago moved to 
taking care of the new GPLv3


licensed codebase instead.



Lukas

1) https://blog.qt.io/blog/2014/08/20/adding-lgpl-v3-to-qt/

___
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] Command line arguments and DBus integration for QML/Python apps

[Martin Kolman]

Sun, 9 Dec 2018 14:40:30 +0200 Rinigus:

Hi,

I would like to add geo: handling into Pure Maps. While command line 
arguments can be used through Qt.application.arguments in QML, its not 
very clear how to take into account already running instance. Namely, 
we are expected to have only one instance of application running and 
as a result, if some other application calls geo: handler, it is 
expected that the map application will become active and show 
corresponding location.


Yep, that's how I would expect it to work on Sailfish OS as well.

For the record proper support for CLI arguments with the QML interface 
on Sailfish OS is also on my TODO list for modRana and it sounds like it 
might be a good idea to bump it up to keep functional parity with Poor 
Maps in this regard. :)




If I would have full control over application start, as in C++ 
applications, I would probably made:

* DBus interface
* on start checked whether such interface is active/available.
* If active DBus interface is there, would have called corresponding 
DBus method and exited

* If not, started full application

QML/Python apps, such as Pure Maps, are started using sailfish-qml. 
This arrangement, as far as I can see, prevents such handling.


I wonder if maybe some non-graphical QML code could be executed before 
sailfish-qml shows the window. Then potentially the QML coude could 
check via the QML DBUS bindings if the application is already running 
and forward it the command line arguments and then exit. Or start is as 
normal if no instance is already running.


Alternatively, this could be something that could be built into the 
sailfish-qml utility itself - the system has some accounting of what's 
already running so that you will get the already running instance if 
there is one or a new one gets started. Possibly something similar could 
be used to check if an instance is already running & forwarding the argv 
to it via say well known DBUS API or equivalent. In any case source for 
sailfish-qml seems to be here:


https://github.com/sailfishos/libsailfishapp/blob/master/launcher/launcher.cpp


It looks to me that I should write some kind of launcher (Python 
probably) that could be used to either communicate with the main 
application via DBus or start the full application.


Yep, that should work & is a solution that does not need immediate help 
from Jolla developers while still could be shared between insterested 
community projects. DBUS should be easy to use from Python on Sailfish 
OS via Pydbus:


https://together.jolla.com/question/181809/how-to-using-dbus-from-python-on-sailfish-os/

The case where the application is already running is IMHO simple - check 
for the DBUS API being up and forward either the full CLI arguments or 
potentially even individual actions (I think it should be much easier to 
parse the arguments in Python than in plain QML) to the API, then exit.


In case the application is *not* running at the time I'm not 100% sure - 
I guess the Python code would run sailfish-qml to start the application 
as usual, forwarding the CLI arguments ? A couple things are unclear to 
me at the moment:


- Can sailfish-qml actually forward CLI arguments in a way the 
application can access them from either QML or Python ?


- What will happen with the Python instance used for the launcher ? I 
wonder if it might lead to slightly increased memory usage if it 
continues running due to sailfish-qml running being it's child process & 
if it is possible to execute sailfish-qml in such a way that the Python 
process can exit.


- What we be the delay of a Python process starting first, followed by 
sailfish-qml vs sailfish-qml starting directly ? This would likely be 
insignificant but could still be a good idea to measure just in case. 
Also I guess (based on my *very* limited understanding of this) all the 
re-loading/boosting machinery used by Sailfish OS should hopefully be 
unaffected as long as the QML code is launched via sailfish-qml or other 
libsailfishapp based launcher.


Or am I wrong? Maybe there is some better idea for implementation of 
such functionality?


Cheers,

Rinigus


Best Wishes

Martin Kolman




___
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] IAP api

[Martin Kolman]

Tue, 28 Mar 2017 10:38:48 + Iosif Hamlatzis:
Only in theory you can use SDL2 because there is a bug and they 
haven't fixed it.
I think I have seen some fixes for SDL2 being mentioned in the release 
notes of one of the recent releases. But not sure if it fixes the issues 
you mention or if it was unrelated. In any case I recommend to recheck 
with latest Sailfish OS version if the issues still persist (unless you 
have already done that).


The bug I mention is that you cannot have landscape mode and if you 
create a game/app in portrait mode but you render the scene 90 degrees 
so that it looks like it's landscape then they will not accept it in 
the market.


I've tried sending them several games, all rejected for this reason. I 
have informed them of the landscape bug and it was they who suggested 
the rotated rendering. I modified my code and submitted my games but 
again they rejected the games.


Also using the SDL2 library it consumes more power when in background 
than using QML so it was another reason they rejected the games.


Last I think there is difference between the Jolla and Jolla C device. 
For some reason rendering on the simulator for either device works 
using SDL2/SDL2_image, but on the actual device this combination works 
on Jolla but under Jolla C I was told it doesn't render anything just 
displays black background.


As I don't have access to Jolla C device I cannot test/debug on the 
actual device to find the bug

--
Sent from Gmail Mobile


___
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] QtLocstion (5.6) | Re: SDK version 1701 (2.1.0) is released to Early Access

[Martin Kolman]

Mon, 13 Feb 2017 12:04:46 +0200 Pekka Vuorela:

Yeah, unfortunately not all the Qt packages were yet updated. Hoping
we'll soon get QtLocation handled too.
Is there a listing of Qt 5 modules available on Sailfish OS and their 
status (version & usability in Jolla store applications) ? It would be 
very useful for application developers.


___
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] QtLocation | Qt 5.6 - alternatives (PinchMap)

[Martin Kolman]

Mon, 02 Jan 2017 01:09:49 + Helicalgear .:

Hi,

Qt5.2 itself provided the "QtLocation" as you see.
But, unfortunately, QtLocation is not allowed to use for 3rd party 
apps officially, right now.


Please see "Sailfish FAQ"
https://harbour.jolla.com/faq#QML_API
And the list of modules which can be used by 3rd party apps.
https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blob/master/allowed_qmlimports.conf

The number of listed modules is increasing time by time.
I think we have no choice but to wait for that the QtLocation add to 
the list if you want to release your app officially (by Jolla Store).
There are other - possibly less convenient but Jolla Store copamatible - 
ways of showing a map on Sailfish OS than Qt Location.


Probably the most used Qt Location alternative is the PinchMap QML 
element, which was originally written for the Qt port of AGTL (Advanced 
Geocaching Tool for Linux) but has since found its way to many 
mapping-related applications on Sailfish OS and elsewhere. It usually 
supports just display of tiled map layers and simple POI, but can be 
quite easily extended & tweaked it's implemented completely in QML. 
Thanks to this it's also totally independent on Qt Location and is 
already used by applications in Jolla Store, such as modRana or Foursail.


As for where to "get" the PinchMap QML element - at the moment its 
basically being used as a copy-lib with various applications including 
the PinchMap.qml file as part of their source code, usually with various 
twekas, changes and improvements. These are the PinchMap.qml versions I 
know about:


https://github.com/webhamster/advancedcaching/blob/master/advancedcaching/qml/PinchMap.qml
- this is the basically the original version targeting 
Harmattan/N9/QtQuick 1.1


https://github.com/Maledictus/foursail/blob/master/qml/PinchMap.qml
- PinchMap as used by Foursail (QtQuick 2.0)
- should be fairly self contained

https://github.com/jmlich/devconf-sailfish/blob/master/qml/PinchMap.qml
https://github.com/rh-lab-q/confla-android/blob/master/PinchMap.qml
- these look like possibly a bit more modern versions with some 
app-specific tweaks


https://github.com/M4rtinK/modrana/blob/master/modules/gui_modules/gui_qt5/qml/PinchMap.qml
- PinchMap as used by current stable modRana release branch
- quite heavily tweaked and improved
- uses a Python backend via PyOtherSide for tile download/storage/lookup
- has some support for showing POI markers and routes

https://github.com/M4rtinK/modrana/blob/master-better_tile_display/modules/gui_modules/gui_qt5/qml/PinchMap.qml
- further improved PinchMap version
- provides flicker free & more efficient tile display support via a 
custom QML-side tile data model

- still has some bugs, especially in its coordinate conversion functions
- will be part of a modRana stable release once the bugs are ironed out


Other than PinchMap, there is also Maep which I *think* might be also 
adapted as a map widget:

https://github.com/dcaliste/maep-qt

Also I guess worst case one could also use a web-view and some of the 
Javascript based tiled-map frameworks such as Leaflet.


Or, I think that you can try to release your app by other way like 
OpenRepos ( https://openrepos.net/ ).


Best regards,

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] CalDAV/CardDAV Contributor Meeting

[Martin Kolman]

Syyyeyeysseyeys

On Thu Oct 6 12:01:01 2016 GMT+0200, Chris Adams wrote:
> Hi everyone,
> 
> Sorry for top-posting, but I'm on an Outlook Web Access client, and it 
> doesn't do quoting.
> 
> This is just a reminder that this coming Monday the 10th of October we have 
> another CalDAV/CardDAV Contributor Meeting at 0900 UTC.  The agenda can be 
> found: 
> https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions#10.2F10.2F2016_Meeting
> 
> Everyone is welcome to attend, even if you are unable to actively contribute 
> at this time.
> 
> Some highlights from the last month of collaboration:
>  - we have a test VM set up in the Mer infra, plan is to install 
> CalDAV/CardDAV services on it ASAP but first we need to sort out 
> authentication / logins.
>  - I've written a unit test framework for CardDAV to easily allow adding unit 
> tests for parsing server responses
>  - Damien Caliste has started writing a unit test framework for CalDAV, and 
> he has also investigated a variety of CalDAV bugs which are proving to be 
> quite tricky.
> 
> See you at the meeting on Monday :-)
> 
> Best regards,
> Chris.
> 
> 
> From: Chris Adams
> Sent: Friday, September 09, 2016 11:55 AM
> To: Sailfish OS Developers
> Subject: CalDAV/CardDAV Contributor Meeting
> 
> Hi everyone,
> 
> During the recent Sailfish OS Community Meeting, I raised the topic of 
> CalDAV/CardDAV sync plugins for discussion.  These plugins provide vital 
> functionality, but due to the complexity of the space (e.g., dozens of 
> different server implementations, each with slightly different behaviour) 
> coupled with resource limitations in Jolla, there have always been issues 
> with them.  I asked the community if there would be anyone interested in 
> contributing in some way, and the response was fantastic!
> 
> As a result, I have created the following wiki page: 
> https://sailfishos.org/wiki/CalDAV_and_CardDAV_Community_Contributions.  
> Please note that currently that SFOS wiki is not able to be edited by 
> community members (we're still trying to figure out how to create a proper 
> review process for edits, and also whether or not it makes sense to provide 
> single-sign-on between Mer and SFOS wiki, etc) but if you have any changes 
> you'd like to make, please send them to me and I can publish them there.
> 
> Also, I would like to organise a kick-off meeting in #mer-meeting on Freenode 
> IRC this coming Monday the 12th of September at 0900 UTC (which is 7 pm 
> Australian Eastern Standard Time, if that helps anyone else ;-)
> 
> The agenda can be found in the wiki page.
> 
> Everyone is welcome and invited to attend, even if you cannot volunteer to 
> help at this point in time.
> 
> If you cannot make it, don't worry, I will attach minutes from the meeting to 
> the wiki page :-)
> 
> Best regards,
> Chris Adams.
> 
> 
> ___
> 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] Available today 1pm EET: Sailfish Community Program & Jolla C second batch

[Martin Kolman]

Tue, 14 Jun 2016 12:05:48 +0200 James Noori:

About the Harbour issue:

All of the developers should technically be here on the Devel mailing 
list as we do not have a separate mailing list for Harbour members.
I think the idea is to send an email to all developers registered to 
Harbour about such things - like a *developer* program. :)


There could be a non trivial amount of people who registered to Harbour 
and develop/want to develop applications for Sailfish OS

but are not subscribed to the sailfish-devel mailing list.



James

On 2016-06-14 09:39, r0kk3rz wrote:

James, is it possible to also send this message to Harbour developers?

This was a criticism of the last batch announcement, and it makes 
sense that you might want harbour developers to join the program too.


On Tue, Jun 14, 2016 at 7:17 AM, Jolla Community > wrote:


/Dear all on the Sailfish Developer mailing list,/

We are super excited to announce that we’ve secured a new batch
of Jolla C devices, and can thus take more participants to the
Sailfish Community Device Program . The
new batch is a very limited one, meaning that we can take only a
few hundred new participants to the program.

This is a heads up for all of you on the Sailfish developer
mailing list. The Jolla Shop for the program
 (LINK) will open to everybody _today June
14th at 1pm Finnish time (noon CEST)_. As it is a very limited
batch please be quick to secure your place and your very own
Jolla C device.

Read more about the Sailfish Community here
, and check the Jolla C product
page .

*For a smooth Jolla Shop experience:*

To secure your place in the Sailfish Community Device Program and
get the Jolla C, please keep in mind the following when entering
the Jolla Shop:

1. Select and save your country/region for the Jolla Shop from
the drop-down menu at the bottom of the page  – see below for
reference:

Country and Region image

2. Sometimes an order gets stuck in "Waiting for Payment" status.
Should this happen to you, we kindly advise you to complete a new
order at your earliest convenience; please do not attempt to fix
or otherwise redo an existing order. While this may lead to
having multiple failed orders with this status, our experience
has shown that eventually reordering will result in a
successfully completed order.  Jolla will then cancel any orders
in the shop that are stuck in "Waiting for Payment" status
without prior consent or notification.

If you did not secure your place already, we hope to see you soon
in the Sailfish Community Device Program!

Kind Regards,
James Noori, on behalf of the Jolla 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 todevel-unsubscr...@lists.sailfishos.org




___
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] Open source in-app ad API helper for QML - please, join

[Martin Kolman]

Tue, 31 May 2016 07:13:33 + Peter Kovacs:


Ads are a classic earn design. As buying an App.
Some Open Source enthusiasts are oppose these ways. And you find them 
in the Jolla Platform, because jolla is much closer to these 
idealistic views then Apple or Android.


I personally don't not mind Ads, if I can switch them off for a 
donation/buyoff. But this is only me.


Yeah - as long as there is a way to pay the developer not to show the 
adds I would be fine with that (one needs to support the developers, 
especially on Sailfish OS).
On the other hand I would most probably simply not use an app where the 
ads can't be "paid off".


Maybe Crowed funding developing method is the only way Hardcore OSS 
people would accept?


I would personally more focus on guidelines how to use ads.

All the best
Peter


Tone Kastlunger <users.giulie...@gmail.com 
<mailto:users.giulie...@gmail.com>> schrieb am Di., 31. Mai 2016, 08:58:


This is an excellent discussion point; I believe this is a very
clear aspect of the key problem of SFOS at the moment - the whole
point of SFOS is to DIFFERENTIATE itself from android.

Note : I love coding for SFOS, it's inspiring and motivating.
Sure, it has it's limitations and quirks, but still, its a great
experience IMHO.

The facts are that, if you ask someone the question: "Would you
mind ads in app XX?" they will reply "Hell NO".
But nevertheless, if app XX gets published with ads, and the app
is good, nobody will care about the ads, and use it anyways.

So, this can mean that:

1) nobody wants ads
2) nobody cares if they are there, tho

My experience has been a harsh rejection of ads by the jolla
community, with my app where I had included ads.
In the timeframe the app had ads included, I noticed two trends :
a) people who stopped using the app completely due to the adds
b) people who kept on using it (hence rule 2) applies).

I'd wonder if codign a SFOS app with ads and publish it as an
Android app on the jolla store will actually fix things?


On Tue, May 31, 2016 at 8:20 AM, <zoltan.lu...@gmail.com
<mailto:zoltan.lu...@gmail.com>> wrote:

Yes, that is how it is. Paid model does not work for masses -
maybe iOS is exception to some extent...


I fully understand those who are fed up with annoying ads -
just like me, too.


But it does not imply ads are evil as such. Just they have to
be placed carefully and accordingly...


Anyway, I just wanted to invite other developers for helping
me finishing this 'sdk'...


Zoltán


Andrew Penkrat írta ekkor: 2016.05.30. 23:46

I want to add my experience from the developer's point of
view. I have an Android app with about 1000 installations (and
100 active users). This app has ads as well as an option to
disable them for a $2 donation.

Nobody ever activated this option. So most probably I won't be
able to get any revenue from the app without ads.

2016-05-30 23:22 GMT+03:00 Martin Kolman
<martin.kol...@gmail.com <mailto:martin.kol...@gmail.com>>:

Mon, 30 May 2016 19:32:54 + Alexey Andreyev:


Hello, Zoltán! :)
Feel free to criticize me, but... ads in our jolla? No,
thanks! :)

I subscribe to this - while I understand developers are
looking for revenue streams I really like
how current native Sailfish OS apps are pretty much add
free (for one reason or another).
Just take a look how reckless add usage ruins application
usability on Android.
I'm fine with donations, paid/premium versions, etc. but
please no adds! :)

I guess if you are a developer it make sence to ask for
donations / create non-free apps, but please, no ads at all.
(Espesially with additional web engine module loaded
eating my resources)

Again, this is just my opinion. I understand it opens new
possibilities for some projects, etc, etc.

пн, 30 мая 2016 г. в 21:48, Zoltán Lutor
<zoltan.lu...@gmail.com <mailto:zoltan.lu...@gmail.com>>:

I've progressed with implementing an open source
wrapper for Vserv RESTful advertisement API in QML.
Quote from API description:

Vserv provides a simple HTTP based API to
publishers/developers and other ad networks, etc.
to fetch ads for mobile sites or mobile
applications. The mobile device / server makes a
HTTP request to Vserv Marketplace server with the
required parameters and in response receives the
  

Re: [SailfishDevel] Open source in-app ad API helper for QML - please, join

[Martin Kolman]

Mon, 30 May 2016 19:32:54 + Alexey Andreyev:


Hello, Zoltán! :)
Feel free to criticize me, but... ads in our jolla? No, thanks! :)
I subscribe to this - while I understand developers are looking for 
revenue streams I really like
how current native Sailfish OS apps are pretty much add free (for one 
reason or another).
Just take a look how reckless add usage ruins application usability on 
Android.

I'm fine with donations, paid/premium versions, etc. but please no adds! :)
I guess if you are a developer it make sence to ask for donations / 
create non-free apps, but please, no ads at all.

(Espesially with additional web engine module loaded eating my resources)

Again, this is just my opinion. I understand it opens new 
possibilities for some projects, etc, etc.


пн, 30 мая 2016 г. в 21:48, Zoltán Lutor >:


I've progressed with implementing an open source wrapper for Vserv
RESTful advertisement API in QML. Quote from API description:

Vserv provides a simple HTTP based API to
publishers/developers and other ad networks, etc. to fetch ads
for mobile sites or mobile applications. The mobile device /
server makes a HTTP request to Vserv Marketplace server with
the required parameters and in response receives the ad in
JSON format. This single API integration gives you the
flexibility to fetch banner/ full screen / rich media ads.

Available implementation is in pre-beta phase - quite majority of
functionality works but there is still room for improvement.

Since I'm not so experienced in this area of sw development - and
especially newbie in Sailfish native development - */I would like
to ask some help from the community in finishing it/*.

It would be a general purpose QML wrapper around the API with
necessary tailoring is needed for Sailfish - e.g. Webkit vs.
WebView, etc. Maybe separate git branches are needed for different
implementation(?) - I'm open for any reasonable proposal.

Is there anybody willing to join? Reviewing, commenting - and of
course, coding is more than welcome. [This is my first open source
project, so comment from this aspect is welcome, too.]

API descrption is here

,
code repository is in BitBucket


Br,

Zoltan

___
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




___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Workflow for co-development for desktop / sailfish silica

[Martin Kolman]

Fri, 23 Oct 2015 15:21:47 +0200 Te:

Thanks for the input, Almicar and Hassan,

I successfully tried sailfish-reload on (Arch) Linux and will 
definitely use it in the future as it *really* speeds up development.


Hassan's tips seem to resemble the sailfish-reload internals in a 
manual way (which is also nice to know, especially as an emacs power 
user --> I tried to get rid off QtCreator long time ago).


Anyhow, I'm still interested in co-developing for different targets, 
as I have a laptop with deactivated virtualization (password protected 
BIOS). Accidently, I stumbled upon QQmlFileSelector / QFileSelector 
which sound promising. Maybe it is possible to have a common base of 
C++ and js files and the respective QML component files are switched 
depending on some characteristic selector.
I'm using Universal Components[0] for the modRana[1] UI - they make it 
possible to have just a single set of QML files for both Desktop/Android 
(using the Controls UC backend) or Sailfish OS (using the Silica UC 
backend). :)
So I can just run the app natively on my Linux (Fedora 22) desktop 
during development, which makes the code/run/debug cycles lightning fast. :)


BTW, as for what editor/IDE I'm using - Pycharm & vim; I don't actually 
even have the SDK installed and I'm using the Mer OBS[2] for package 
building. :)


Martin

[0] https://github.com/M4rtinK/universal-components
[1] https://github.com/M4rtinK/modrana
[2] https://build.merproject.org/


Has anyone used QQmlFileSelector for Sailfish development?

Cheers,
Thomas


On 22.10.2015 18:25, Mohammed Hassan wrote:

On Thu, 22 Oct 2015 15:43:46 +0200
TE  wrote:


Hi all,

until now, my development workflow consists of coding and
subsequently testing on the device or emulator respectively. Every
cycle takes quite some time. Is there a neat way / architecture for
co-developing for the desktop and Silica UI. The aim would be to do
most of the coding / testing with the desktop target and switch to
the emulator / device for the Silica UI.

I would be grateful if anybody could share his/her experiences or
workflow!

There are multiple tips if you are using Linux AND you don't care
about QtCreator:
- I use a multi-tabbed terminal. The first tab has emacs (console not
   X11) editing code. Once I am done with the code, I switch to the 2nd
   tab.
   The 2nd tab is a tab dedicated for typing 1 command: sb2 make && scp
phone:~/app_test_dir/
   The 3rd tab is a phone ssh session where I just ^c and rerun the app
   to check it.

- Sometimes I edit QML code on the phone and restart the app to check
   but you have to be capable of tolerating vi (The editor on the 
phone).


- C++ engine is easily testable on the desktop. Not a big issue IMHO.

- You can try installing Silica on the desktop especially that there
   are now x86 binaries. This can speed up your development. I have not
   done that so I unfortunately cannot help here but it should be 
doable.


HTH

Cheers,


___
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] About applications presenting a map interface

[Martin Kolman]

Sat, 12 Sep 2015 22:33:31 +0200 David Van Rijn:

Hi Guys,

I definitely agree that there should be an easy way to add a map in 
any application. This would make things so much more efficient. I 
believe there were some mails earlier in this group about storing all 
the cached tiles in the same place, so apps can share them.
Yeah, I made the "Well known map data path" proposal a while ago but 
unfortunately there were not many reactions or feedback since then. But 
everybody is of course welcome to use or extend the specification. :)


Also on a related note - I have been recently working on a rewrite of 
modRanas tile storage code to make it much more flexible & robust. The 
result should be that in the future modRana should be able to look for tiles
at multiple places simultaneously - for example in its own tile storage 
location, in a well known/shared tile storage location or even possibly 
in the tile storage locations of other apps (if compatible). :)




A while ago i started with bulding my own 
 slippy-map application to 
do just this. It uses Qt scene graph, so it should be really quick and 
efficient. It is not finished yet (rotating and zooming are hard to 
combine), but it might be interesting nontheless.
Any idea if you can make some use of the mapbox-gl-native vector map 
renderer[2) ? Maybe as a special tile provider ? The output looks 
marvelous and it's also C++ and they even have some initial Qt 5 
support[3] (QWidget only at the moment though).


[1] https://lists.sailfishos.org/pipermail/devel/2014-March/003731.html
[2] https://github.com/mapbox/mapbox-gl-native/
[3] https://www.mapbox.com/blog/qmapboxgl/



Cheers,

David

2015-09-10 20:30 GMT+02:00 Kim Foder >:

Hi Juice

I'm using Pinchmap from Foursail, it's a qml/javascript
implementation of a
slippery map, and works great, at least for my use ;)

/Kim

On Thursday 03 September 2015 08:14:27 juice wrote:
> Morning.
>
> This might well be a FAQ but I could not find the answer
browsing thru
> the mailing list archives.
>
> I see that currently QtLocation and QtPositioning are still not
allowed
> in Harbour.
> This seems to me that I cannot use a Map object in QML.
>
> What is approved the method to present a map interface (openmaps for
> example) in an application and still have it possible to submit the
> application to the store?

___
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



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] QtFeedback 5.0 not allowed? Really?

[Martin Kolman]

Wed, 29 Apr 2015 12:56:20 + Kimmo Lindholm kimmo.lindh...@eke.fi:

Any news about whitelisting QtFeedback?

-kimmo
Also what about QtPositioning ? I know that the pull request for RPM 
validator has already been merged a while ago,
but when I recently tried to submit an application using QtPositioning 
to Harbour, I got a reply that is actually still not yet allowed...


Martin




-Original Message-
From: devel-boun...@lists.sailfishos.org [mailto:devel-
boun...@lists.sailfishos.org] On Behalf Of Reto Zingg
Sent: 2. joulukuuta 2014 11:00
To: devel@lists.sailfishos.org
Subject: Re: [SailfishDevel] QtFeedback 5.0 not allowed? Really?

Hi,

On 01.12.2014 23:34, sailfishmail wrote:

Another observation:

You're allowed to require qt5-qtfeedback in your RPM-packaging
according to the faq:
https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blob/1.18/all
owed_requires.conf


It's a mistake that qt5-qtfeedback made it into the allowed_requires.conf file.

It's out for update 10:
https://github.com/sailfish-sdk/sdk-harbour-
rpmvalidator/blob/1.21/allowed_requires.conf

As soon as this libQt0Feedback.so.0 naming mess (note the 0 between Qt and
Feedback!) is clean up, we will allow QtFeedback in Harbour (will probably not
make it to the next update, but in a later one).

br
Reto


which installs
/usr/lib/libQt0Feedback.so.0
/usr/lib/libQt0Feedback.so.0.0
/usr/lib/libQt0Feedback.so.0.0.0
/usr/lib/qt5/qml
/usr/lib/qt5/qml/QtFeedback
/usr/lib/qt5/qml/QtFeedback/libdeclarative_feedback.so
/usr/lib/qt5/qml/QtFeedback/plugins.qmltypes
/usr/lib/qt5/qml/QtFeedback/qmldir

However, according to
https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blob/1.18/all
owed_libraries.conf
and
https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/blob/1.18/all
owed_qmlimports.conf you're not allowed to use what you required to be
installed.

Maybe some misunderstanding when making the harbour validation scripts?

-Asser

Mon, 01 Dec 2014 22:08:34 +0100
Peter Pykäläinen peter.pykalai...@gmail.com kirjoitti:


Thanks Kimmo!

That was new.

And it fails:

Libraries
=
ERROR [/usr/bin/harbour-sailraid] Cannot link to shared library:
libQt0Feedback.so.0
INFO [/usr/bin/harbour-sailraid] Please see our FAQ here:
https://harbour.jolla.com/faq#Shared_Libraries
FAILED


Requires

ERROR [libQt0Feedback.so.0] Cannot require shared library:
'libQt0Feedback.so.0'
INFO [harbour-sailraid] Please see our FAQ here:
https://harbour.jolla.com/faq#2.6.0 how to use
'__provides_exclude_from' and '__requires_exclude' .spec file to
avoid that FAILED

And it fails totally.
Not fun.

So no vibration then, how can this basic stuff not be accepted?

// Peter Pykäläinen

On 1 December 2014 at 22:57, Kimmo Lindholm kimmo.lindh...@eke.fi
wrote:


   Run the pre-validation tool from SDK, if you get green there, it’s
much closer to approval…



(I prefer accessing it through browser,
http://127.0.0.1:8080/C/harbour_tools/ )



-kimmo



*From:* devel-boun...@lists.sailfishos.org [mailto:
devel-boun...@lists.sailfishos.org] *On Behalf Of *Peter Pykäläinen
*Sent:* Monday, December 01, 2014 10:34 PM
*To:* Sailfish OS Developers
*Subject:* Re: [SailfishDevel] QtFeedback 5.0 not allowed? Really?



Hi,

yes I did, thank you all for your help.

Especially Andrey, you are the man!

Let's see now if this passes harbour QA or not :)



// Peter Pykäläinen



On 1 December 2014 at 22:30, Gabriel Böhme
m.gabrielboe...@googlemail.com wrote:

Have you tried cleaning the project? Helps sometimes.

Am Mon Dec 01 2014 21:18:17 GMT+0100 (CET) schrieb Peter Pykäläinen:


I give up!

Once I figured out how to add the stupid haptics stuff into the
.pro

file I

then get errors on my main when I try to compile:

error: undefined reference to `SailfishApp::application(int,
char**)' error: undefined reference to `SailfishApp::createView()'
error: undefined reference to `SailfishApp::pathTo(QString const)'

I have used this kind of code succesfully in my other app and no
issue there.

Any help would be much appreciated.

My main looks like this:

#ifdef QT_QML_DEBUG

#include QtQuick

#endif


#include sailfishapp.h

#include rumbler.h

#include QQuickView

#include QQmlContext

#include QGuiApplication



int main(int argc, char *argv[])

{

  // SailfishApp::main() will display qml/template.qml, if you
need

more

  // control over initialization, you can use:

  //

  //   - SailfishApp::application(int, char *[]) to get the

QGuiApplication *

  //   - SailfishApp::createView() to get a new QQuickView *
instance

  //   - SailfishApp::pathTo(QString) to get a QUrl to a
resource file

  //

  // To display the view, call show() (will show fullscreen on

device).


//return SailfishApp::main(argc, argv);

  QScopedPointerQGuiApplication
app(SailfishApp::application(argc,

argv));

  QScopedPointerQQuickView view(SailfishApp::createView());


  Rumbler rumbler;


  

Re: [SailfishDevel] Commercial apps - when?

[Martin Kolman]

Fri, 24 Apr 2015 16:22:43 +0200 Marcin M. marmistrz...@gmail.com:
Martin: free software is really great unless you have to pay for a 
place to sleep and for stuff to eat, e.g. as a univerisity student. 
You don't get a big revenue from donations unless you create something 
really big (e.g. the Whatsapp clients). And you rarely create big 
stuff. If you need money for such things, a payment in a store is 
superior to a donation method. Correct me if I'm wrong.
Of course you can't depend on donations as your sole source of income 
(well, unless you re developing Dwarf Fortress[0] :) ), but they are 
still a nice appreciation of all the hard work developers do *in their 
free* time to give software and applications to users *for free*. So it 
is should be as easy as possible for users to appreciate the work 
developers of free (and often also open source) software do, preferably 
by directly integration it in the application repository.


And I don't think you can say donations and payments can be superior to 
each other as I see them as two separate things that might even be 
sometimes combined (I can actually imagine someone sending a donation to 
the author of a paid

application if the person really likes the app).

Best Wishes
Martin Kolman

[0] http://en.wikipedia.org/wiki/Dwarf_Fortress#History



--
Marcin

2015-04-17 0:49 GMT+02:00 Martin Kolman martin.kol...@gmail.com 
mailto:martin.kol...@gmail.com:


Thu, 16 Apr 2015 05:27:46 + Karl Granström
karl.granst...@jolla.com mailto:karl.granst...@jolla.com:

Hi,

We are still working hard on it but the tablet support work
has been eating our resources from this area. But some good
news is that we are planing to launch the donation support in
Store in really near future.

That's a really good news! Especially for for developers that
don't want to place any artificial barriers (such as requiring a
payment) between users and their applications but still want to
give the users a way of showing their gratitude and helping with
furter development. :) This seems to work quite nicely in the
Mozilla extension repository and elsewhere, so it is really good
the see it also coming to the Jolla store. :)

Best Wishes
Martin Kolman


Br,
Karl

On 15 Apr 2015, at 20:06, Marcin M.
marmistrz...@gmail.com mailto:marmistrz...@gmail.com
wrote:

Hi,

Any ETA for the support for commercial apps for Sailfish?
IIRC, it was the second half of 2014, :) so time long past :)

Regards,
--
Marcin
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org

___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org




___
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] Commercial apps - when?

[Martin Kolman]

Thu, 16 Apr 2015 05:27:46 + Karl Granström karl.granst...@jolla.com:

Hi,

We are still working hard on it but the tablet support work has been eating our 
resources from this area. But some good news is that we are planing to launch 
the donation support in Store in really near future.
That's a really good news! Especially for for developers that don't want 
to place any artificial barriers (such as requiring a payment) between 
users and their applications but still want to give the users a way of 
showing their gratitude and helping with furter development. :) This 
seems to work quite nicely in the Mozilla extension repository and 
elsewhere, so it is really good the see it also coming to the Jolla 
store. :)


Best Wishes
Martin Kolman


Br,
Karl


On 15 Apr 2015, at 20:06, Marcin M. marmistrz...@gmail.com wrote:

Hi,

Any ETA for the support for commercial apps for Sailfish? IIRC, it was the 
second half of 2014, :) so time long past :)

Regards,
--
Marcin
___
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



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] (no subject)

[Martin Kolman]

Thu, 18 Dec 2014 18:07:18 +0100 David van rijn davidvanr...@gmail.com:

Thanks for the feedback :)

I had already looked a bit at the monav stuff because i had it on my 
N900, but like you said, it seems abandoned, so i didn't feel like 
using it.


But the Mapbox GL definitely looks primising, i will have a look at it 
later.


I did not know about the qml pinchmap.  I have tried out modrana 
though, and it seems a bit crude, because it's written in python, and 
i can imagine (correct me if i'm wrong) that implementing the whole 
element in qml is a bit recource-unfriendly if you compare it to the 
low-level c++ /updatePaintNode()/ method.
Well, I'm actually to this day kinda surprised how well it works, 
considering how it is implemented. Most probably thanks to the original 
clever idea the AGTL developer had of using a fixed tile grid and just 
shifting the coordinates of the tiles in the grid when panning the map. 
The QtQuick image cache then takes care of all the tile caching for you 
and it works surprisingly well. On the other hand the hack[0][1] I had 
to implement to enable really asynchronous tile download with caching is 
just plain crazy, but works. :)


The QML-only nature of the widget also helps to avoid more C/C++ 
dependencies that unlike the pure-Python/QML based modRana would need to 
be compiled for the various platforms where modRana is running and it 
also makes it easier to adapt it to the various specific modRanas needs. :)


Still I would not mind adding support for an alternative map widget, 
integrating it with the current one or maybe even using it by default if 
fits to modRanas requirements better than the current solution. :)



I think it would be really cool if it is possible to have all apps use 
the same maps, and have those be configurable somewhere central (like 
in the settings app).
Actually I've tried to propose a common map data storage location for 
the Jollas micro SD card a while ago on this list[3] in a thread called 
[SailfishDevel] [RFC] Well known map data path but it unfortunately 
did not get any traction back then. So maybe the proposal can be 
salvaged or even extended to cover map data sharing in internal storage ?


BTW, shared map data storage worked/works quite nicely on the N900 - 
there is /home/user/MyDocs/.maps folder that various third part mapping 
and navigation apps (modRana, Mappero, Maep, Cloud GPS, etc.) use for 
storing  sharing map tiles. So it would be nice to have the same thing 
also on the Jolla/Sailfish OS. :)


Actually, there already seem to be some early positive results from 
users enabling tile sharing between modRana and Poor Maps[3]. :)





cheers,

David

Regards

Martin

[0] 
https://github.com/M4rtinK/modrana/blob/master/modules/gui_modules/gui_qt5/gui_qt5.py#L549
[1] 
https://github.com/M4rtinK/modrana/blob/master/modules/gui_modules/gui_qt5/qml/Tile.qml#L35

[2] https://lists.sailfishos.org/pipermail/devel/2014-March/003731.html
[3] http://talk.maemo.org/showthread.php?p=1451148#post1451148





2014-12-18 0:16 GMT+01:00 Martin Kolman martin.kol...@gmail.com 
mailto:martin.kol...@gmail.com:


Wed, 17 Dec 2014 16:04:31 +0100 David van rijn
davidvanr...@gmail.com mailto:davidvanr...@gmail.com:


Hello,

Hi!


I am writing a qml component to display a slippy map (eg. google
maps).
(You can look at the code at
https://github.com/unsanded/harbour-mapp.)

The idea is to be able to add maps in qml by just typing
something like:
SlippyMap{
  GoogleMapsProvider{
apiKey: blabla
  }
}
I have a few questions about this:

   - Can it, at some point, become a library for others to use?

Could be certainly interesting and useful! :)


   - What is the best way to implement offline maps/routing?

For offline routing the routino routing utility[0] currently looks
like the best bet for Sailfish.
I have already managed to build it's package for Sailfish[1] and
it appears to be working fine. :)

Another candidate could be the Monav[2] routing daemon, but it's
upstream is dead, it depends on Qt 4 and its source
code has been bit-rotting rather badly.

As for offline map rendering, the Mapbox GL native widget[3] looks
like the best bet, if it could be wrapped in a QML element! :)

I even suggested the QML integration to the Mapbox people, but
they unfortunately replied that they are not interested in doing
that themselves (most probably not to canobalize their iOS 
Android SDKs with a superio solution ;-) ).


   - Is anyone eager to join the project?
   - any other feedback?

Many current Sailfish OS applications are using the QML-only
PinchMap QML element, originally from AGTL, for example:
* modRana[4]
* FourSail[5]
On the other hand the Poor Maps application has a custom solution
based on enhanced QtLocation Map element.

So maybe have a look how these work and what

Re: [SailfishDevel] (no subject)

[Martin Kolman]

Wed, 17 Dec 2014 16:04:31 +0100 David van rijn davidvanr...@gmail.com:


Hello,

Hi!


I am writing a qml component to display a slippy map (eg. google maps).
(You can look at the code at https://github.com/unsanded/harbour-mapp.)

The idea is to be able to add maps in qml by just typing something like:
SlippyMap{
  GoogleMapsProvider{
apiKey: blabla
  }
}
I have a few questions about this:

   - Can it, at some point, become a library for others to use?

Could be certainly interesting and useful! :)


   - What is the best way to implement offline maps/routing?
For offline routing the routino routing utility[0] currently looks like 
the best bet for Sailfish.
I have already managed to build it's package for Sailfish[1] and it 
appears to be working fine. :)


Another candidate could be the Monav[2] routing daemon, but it's 
upstream is dead, it depends on Qt 4 and its source

code has been bit-rotting rather badly.

As for offline map rendering, the Mapbox GL native widget[3] looks like 
the best bet, if it could be wrapped in a QML element! :)


I even suggested the QML integration to the Mapbox people, but they 
unfortunately replied that they are not interested in doing that 
themselves (most probably not to canobalize their iOS  Android SDKs 
with a superio solution ;-) ).



   - Is anyone eager to join the project?
   - any other feedback?
Many current Sailfish OS applications are using the QML-only PinchMap 
QML element, originally from AGTL, for example:

* modRana[4]
* FourSail[5]
On the other hand the Poor Maps application has a custom solution based 
on enhanced QtLocation Map element.


So maybe have a look how these work and what features these applications 
expect as inspiration work on your project. :)



Cheers,

David

Best Wishes
Martin Kolman
(main modRana developer)

[0] http://www.routino.org/
[1] https://build.merproject.org/package/show/home:MartinK:sailfish/routino
[2] https://code.google.com/p/monav/
[3] https://github.com/mapbox/mapbox-gl-native/
[4] 
https://github.com/M4rtinK/modrana/blob/master/modules/gui_modules/gui_qt5/qml/PinchMap.qml
[5] 
https://gitorious.org/foursail/foursail/source/31644f69c670f5f012f98bee641e1b7e50ba4e1f:qml/PinchMap.qml
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] QtQuickDialogs - QtQuickControls

[Martin Kolman]

Wed, 17 Dec 2014 01:58:11 +0500 Andrey Kozhevnikov coderusin...@gmail.com:
QtQuickControls are not available for SailfishOS. You can only use 
native Silica components or plain QtQuick 2.x. Jolla (company) not 
supporting 3rd party components which are looking different. But you 
are also welcome to port QtQuickControls to SailfishOS yourself :)
As I think QtQuick Controls would be really nice to have on Sailfish OS 
(and I'm quite surprised there are not yet available, at least in the 
repositories), so I've opened a new question on Together to track this:

https://together.jolla.com/question/71520/request-qtquick-controls/

Best Wishes
Martin Kolman


17.12.2014 01:53, Alex Smirnoff пишет:

Hi,
With the help of Gcompris community I try to port Gcompris 
Educational Software to Sailfish OS.
The last problem that we encountered - we could not start application 
because of unresolved dependencies.


The two modules are missing: QtQuickDialogs and QtQuickControls.
Gcompris uses them because they add portability.

It looks like that the official repository does not have this modules.

I have tried to check 3rd party repositories, but was not able to 
found up-to-date packages.


Could any one help me to find the way to have this modules on Sailfish?

--
Alex Smirnov


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail todevel-unsubscr...@lists.sailfishos.org




___
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] Boot Up Times

[Martin Kolman]

22.11.2014 v 03:01 Chris Sparks:

Hello everyone,

I am very curious as to boot times for devices that use Sailfish OS 
(tablets or cell phones).


I am considering trying to repurpose my Samsung Galaxy Tab 3 to 
something faster than

Cyanomgen Mod.  19 seconds.
You can use the the systemd-analyze utility to accurately measure 
startup time:


$ systemd-analyze
Startup finished in 5.191s (kernel) + 56.800s (userspace) = 1min 1.991s

And if you run systemd-analyze blame, it will show you a list with each 
service started  how long it took.


So I'd be curious to hear what folks have achieved.  I suspect the 
leaner the system the faster.


Also I'd like to get my hands on how to install this OS onto a 
device.  I'll be hunting around

the web tonight.

Thanks,
Chris

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

___
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] Building command line Linux tools for jolla

[Martin Kolman]

Dne 11.11.2014 v 22:04 Philipp Seiler napsal(a):

Hi guys,

It's me once again, asking a question. I already have a Jolla with
some nice native apps but I want to have some command line programms for
that typical geeky linux feeling on this mobile phone. Programs like
zsh as shell, htop, mplayer,...

I already found out that Jolla/Sailfish uses RPM as package manager so
is there a public Open Build Service where I can build my tools against
current sailfish versions?

Sure, here:
https://build.merproject.org/

To get an account just register to the Mer Bugzilla and wait 10 minutes.

I'm using it for building my Sailfish OS packages and it works just fine. :)

Kind Regards
Martin Kolman



br,

Philipp



___
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] Minimized Apps

[Martin Kolman]

8.9.2014 21:44, r0kk3rz:
I'm not expecting someone to fix my bug for me, just describe or point 
to a link or something that tells me what happens when a Sailfish App 
is minimized (status objects changed, signals that are called, anything?)


It's a QtMultimedia based music player app, and my play queue stops 
updating the datamodel when the player reaches the end of one song and 
goes to the next in the queue, the player itself continues to work, 
but the datamodel that displays in the GUI becomes stops updating. 
This happens only when minimized, when the app is in focus the app 
works as expected.
Does this happen also when the screen is on or off ? When the screen is 
off Sailfish behaves a bit like Android, freezing running apps/running 
timers after a few minutes, unless explicitly told otherwise.


Code is available here: 
https://github.com/r0kk3rz/SirenSong-Media-Player but again I'm not 
expecting anyone to fix it for me, just help me understand the 
environment better.


On Mon, Sep 8, 2014 at 8:23 PM, Michael Neufing m.neuf...@yahoo.de 
mailto:m.neuf...@yahoo.de wrote:


Hello,

I think, without further information on what your app does and
what bug occurs when your app is minimized, nobody is able to help
you.


Regards,

Michael Neufing


r0kk3rz r0kk...@gmail.com mailto:r0kk...@gmail.com schrieb am
18:47 Montag, 8.September 2014:


Hi,

Can someone explain what happens when an App gets minimized to the
home screen on Sailfish?

I have a bug that only occurs when the App is in minimized state,
and without really knowing what changes to look for it makes
debugging hard.

Regards,



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org




___
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] Import paths

[Martin Kolman]

19.8.2014 19:35, Chris Walker:

In this document -
https://github.com/sailfish-sdk/libsailfishapp/blob/master/docs/documentation.mdown
it says 'ToDo: Describe where to install private QML imports, how to
import them in QML code, how libsailfishapp sets the import path and
the naming requirements for Harbour QA.'

Is there any such documentation or can anybody here point me to some
docs describing the import? I'm struggling to make an import path work.
I would would also really like to know how to properly do this. It can 
easily be done
with qmlscene - you just use -I and point to the folder where your QML 
plugin resides.
But with qmlscene I need to resort to hideous packaging hacks (basically 
butchering the
QML-only plugin folder to be in the same folder as the main.qml file and 
then replacing
Import foo 1.0 by Import ../foo) that are both very very ugly and 
fragile.



___
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] More executables in one package

[Martin Kolman]

1.8.2014 21:24, Micha? Radwan'ski:

Actually, SailfishOS uses Zypper (it's openSUSE derivative).

Actually it uses packagekit and Zypper is not even installed by default.

As far as I know, there are differences between Fedora RPM's and 
openSUSE RPM's.
Well I would be very surprised if there was such a huge difference such 
as a totally different executable placement mechanism...



2014-08-01 20:37 GMT+02:00 Andrey Kozhevnikov coderusin...@gmail.com 
mailto:coderusin...@gmail.com:


there is nothing special for sailfishos. use general rpm techniques.

02.08.2014 00:31, Micha? Radwan'ski ?:

I want to make C/C++ IDE for Sailfish OS. How to add two (or
more) executables to RPM? Or have I to make another app like
$(MyApp)-g++?

Envoyé de mon iPhone
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org


___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to
devel-unsubscr...@lists.sailfishos.org
mailto:devel-unsubscr...@lists.sailfishos.org




___
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] Measuring distance with GPS

[Martin Kolman]

7.7.2014 20:13, Timur Kristóf:

Hi,

I'd like to ask a simple question: what is the simplest way to make a 
Sailfish app that measures the distance the user has walked. 
Preferably using QML only, but I'm not afraid of writing QML code either.
Just use the QtPositioning QML interface[0], it should give you 
everything you need - current position and support for computing 
distance between coordinates.


[0] http://qt-project.org/doc/qt-5/qtpositioning-qmlmodule.html


Thanks,
Timur


___
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] Updates to resource policy implementation in QtMultimedia (update8)

[Martin Kolman]

3.7.2014 12:57, Juho Hämäläinen:
Only one media player or audio output object can be in playing state 
at given time. Last object acquiring resources gets the resources.
Will the control revert back to the previous owner once the 
last-one-in gives up the resource ?


This would be handy for the planed voice directions in modRana for users 
playing music during navigation:

0) music playing
1) modRana acquires audio, this stops music
2) modRana plays the direction message
3) modRana drops the audio resource, this restarts music playback

Best Wishes
Martin Kolman



___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Follow up on faenil's topics in Community meeting 24.04.2014 @ 10:00 UTC

[Martin Kolman]

25.6.2014 17:16, Andrea Bernabei:
DISCLAIMER: I'm saying the following words with a smile on my face, I 
may sound harsh but please believe me, I don't mean to :)


Eric, just go into the IRC channel, and ask people there (who are, 
usually, the most active community members):


Sorry for the late reply, I've promised to write my reaction to the ML 
to Faenil, but did not got to it until now. :)

1) what do you think of TJC as a bug reporting tool?
From my experience of using extensively Bugzilla daily I would say that 
while TJC definitely has a lower barrier to entry than a normal Bugziilla
instance. Every Jolla user has an account and TJC serves also other uses 
than bug reporting increasing its visibility.


On the other, for the same reasons the the signal to noise ratio is 
pretty bad - you have to dig for bug reports in tons of unrelated crap. 
That the tool was not designed
from the ground up doesn't help. There are no components/maintainers, 
bug states, attachment upload, bug classification, templates, bug 
linking, etc.



2) do you think it can work?
Sure it can but with quite bad efficiency for both bug reporters and 
developers.



but most importantly
3) Are you *actually* reporting bugs on TJC?

Sure:
https://together.jolla.com/question/39842/bug-sharing-an-image-to-twitter-does-not-validate-message-length/
https://together.jolla.com/question/9306/bug-volume-button-cant-be-used-by-android-applications/
https://together.jolla.com/question/16827/bug-positioning-gives-bogus-numbers-for-horizontalaccuracy-and-verticalaccuracy/
https://together.jolla.com/question/16518/bug-if-cover-element-fails-to-load-application-doesnt-exit-when-closed/
https://together.jolla.com/question/16827/bug-positioning-gives-bogus-numbers-for-horizontalaccuracy-and-verticalaccuracy/
All in all I got any kind of feedback only for the last. If there has 
been any followup on any of the other ones on Jollas side,

I haven't seen them on my end of the tube.

I have also opened quite a few RFE and there similarly has not been much 
feedback from Jolla, at least lately.


If others have the same experience I'm afraid they might get the idea no 
one on the other end is listening and

might stop submitting further bugs and RFEs due to the lack of feedback.




I heard many people who are not reporting bugs on TJC because they 
think it's not worth it (for different reasons)
and I'm not reporting them myself, because I keep stumbling on 
unanswered posts.


But that is normal, sailors are not developer-care agents, they can't 
spend all day reading all kind of reports trying to understand which 
bug is valid, which one is invalid, and then also keep those posts 
updated with the news!

Just a simple suggestion that came up when discussing this on IRC:

Tag the TJC bugreports with Jolla bugzilla numbers!

While one reaction to this proposal on the IRC was that it would be rude 
to use internal bug numbers if the bugzilla itself is currently closed,
I think it would be a good form of feedback and acknowledgment that the 
given bug is being worked on. It would also help with bug tracking
and deduplication as bugs would have an unique identifier that actually 
maters.


And if not using the Jolla bugzilla numbers, just a simple bug_filled 
tag would do wonders to at least provide some of feedback.


With some sort of automation I guess this could be extended with a 
bug_closed_x (fixed/wontfix/notabug) tag to provide

more feedback and get us a bit closer to proper bug workflow.


Hence my point...



Kind Regards
Martin Kolman
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] was Acceptable Behaviour.. -- Forum

[Martin Kolman]

24.5.2014 19:32, Thomas B. Rücker:

* karma: so distracting, I prefer the simple egalitarianism /
meritocracy of mailing lists

Could be folded into a mailing list feature too, just to annoy you. Just
kidding. But knowing the Intarwebz™, someone has done that already…


IIRC, the new Mailman 3 web interface called HyperKitty[1] has this. :)

BTW, check it out, other than this gimmick the UI has reportedly many
interesting and useful features. :)

[1] https://fedorahosted.org/hyperkitty/
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org

Re: [SailfishDevel] Acceptable Behaviour Guidelines - you decide

[Martin Kolman]

23.5.2014 21:21, christopher.l...@thurweb.ch:

Hi Jarko

before we jump to splitting into multiple SF mailing lists, I wonder 
has any thought been given to replacing the lists with a developer' 
forum?


I fear that multiple lists would not really help - I would end up 
subscribed to all of them (both those that I am very interested in, 
and those that I am sometimes interested in), and thus my In-box would 
be just as full as it is now.


A forum would be divided into sub-forums, and being thread oriented 
(as opposed to post-oriented) I could freely choose which sub-forums 
and which threads I chose to dive into, and which to ignore.
Well, roughly the same thing can (and usually is by people subscribing 
to mailing list) achieved by setting up mail filters and redirecting 
email to per-mailing-list folders. I can't even think about all those 
email directly ending in my

main inbox...

Regarding a forum - well, talk.maemo.org is currently basically filling 
the role of the main Sailfish forum and this seems to work just fine, so 
I don't really see the need for yet another forum instance (anybody 
still remembers forum.meego.com ?).




Chris


Zitat von Jarko Vihriala jarko.vihri...@jolla.com:

We're looking into splitting the discussions on SF mailing lists. 
But, let's not make hasty moves and keep the technological part alive.


thanks, Jarko


From: devel-boun...@lists.sailfishos.org 
[devel-boun...@lists.sailfishos.org] on behalf of Ville M. Vainio 
[vivai...@gmail.com]

Sent: Friday, May 23, 2014 9:45 PM
To: Sailfish OS Developers
Subject: Re: [SailfishDevel] Acceptable Behaviour Guidelines - you 
decide



Some of the discussions here have been borderline illegal; 
discouraging such behavior even with absence of 'technical' moderator 
tools (like you have even on barbaric environments like phpbb) is not 
necessarily a bad idea.


On May 22, 2014 5:53 PM, 
christopher.l...@thurweb.chmailto:christopher.l...@thurweb.ch wrote:

Seconded. I could not have put it better myself.

Since the early days I have enjoyed the very open nature of this 
forum where pretty much anything goes that is vaguely Jolla / Qt / 
Open Source / technical.


From my recollection the number of threads that struck me as 
definitely better elsewhere has been refreshingly small. Many of 
the threads have been helpful or and or insightful.


Keep up the good work

Chris

Zitat von David Greaves 
david.grea...@jolla.commailto:david.grea...@jolla.com:


There's been enough noise on this mailing list recently that some 
people have

felt they don't want to participate.

We need to be careful about over-policing discussions but there is 
such a thing

as under-policing too.

How would we (community, not Jolla) determine the line? and what 
measures do we

think should be taken?

Lorn pointed to this as a useful document:
  http://www.kde.org/code-of-conduct/

FWIW I personally don't think there's anything happened recently that 
I would
actually take action over. My delete key works fine and history shows 
that

sometimes cries for help come in strange forms.

David/lbt

PS This thread is for generic guidelines - please keep any specific 
issues out

of it.
___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to 
devel-unsubscr...@lists.sailfishos.orgmailto:devel-unsubscr...@lists.sailfishos.org





___
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to 
devel-unsubscr...@lists.sailfishos.orgmailto:devel-unsubscr...@lists.sailfishos.org






___
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] Starting point for a Swype-like keyboard

[Martin Kolman]

15.4.2014 20:03, Michael Doube:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I recently decided to start working on a Swype-like keyboard

I really like the idea to have some Swype-like input for Jolla - it's
one of the hardest things to leave behind from N9, and something you
really notice when going to plain touchscreen keyboards.

But - are there patents covering this sort of functionality? I don't
want to be the rain at the parade, but presumably the people behind
Swype have some patent lawyers and some IP?

A quick look at the bottom of the Wikipedia entry for Swype confirms
my suspicion... (2 US patents). :-(
Well, they look like to be US patents - so considering the Jolla is not 
even sold in the USA  it would be an external application anyway, I 
don't really see any issue.


Where do app developers and Jolla stand in relation to implementing
patented functionality?

Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTTXRtAAoJEErlWquropJ87M4H/3sWmc6zEW+Z9INgxJXIr0QN
driLcbE3ZaVTI8BfS9GW0L1/TluY6sEnR1TSuqLe1hjVUl2JAcZLgkecTtdt6Amg
0XZspTjEFPYKvHd3uM5ScYxspD87yVXBnoW+nC0wyLTiuCDdH4O+IqJXarD8PqjT
A7t1mtlU96AJ5cba5nGlg3DrDy0yoNFcNewCOwQf1SP90Ew2tMVC2Y63jynx5xK6
ToSkfWZQnRwxKMoZa2OewJdXLtuJYZtvd6XAD6px2JmTlGpGkA8G+OASxMXw0PGC
dpwNaNU8Z+6tYdWmB8gLBeu5hvPbeK2keOiv8ZKKqeIUqeUc6pc9T5G25bXWOxM=
=z6nw
-END PGP SIGNATURE-
___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

[SailfishDevel] [RFC] Well known map data path

[Martin Kolman]

Hi!
With the improved uSD arriving in the latest storage the possibility
to store big data sets on-device is opening for non-expert Jolla users.
One of such potential data sets is mapping and navigation related
data.

With multiple navigation systems for Sailfish already in development
(such as Maep and modRana) it might not be a good idea to discuss the
possibility of having a well known path for map data on external storage
which would make it possible to share data sets between navigation apps.


Background - Maemo 5  N900

There are various mapping and navigation apps for Maemo 5, such as Maemo 
Mapper/Mappero,
Maep, modRana, Cloud GPS, Yosmapa, AGTL and others. By a convention that 
wasprobably set ba Maemo Mapper
as one of the first navigation apps on Maemo 5 store their map data (in 
this case map tiles) in a common location.
This common location is the .maps directory in the MyDocs folder, giving 
the /home/user/.maps path.

Individual map layers each have their own directory, such as for example:
/home/user/.maps/OpenCycleMap

This common tile storage directory makes it possible to share map tiles, 
meaning that tiles for the same place
downloaded by modRana can be viewed in CloudGPS and don't need to be 
downloaded twice.



Proposal - common map data path on Sailfish external storage

Based on the experience from Maemo 5 I would like to propose this set of 
well known map storage paths

for external storage (uSD card partitions) on Sailfish OS:

- base directory:
card partition root/.maps

- tiled data
base directory/tiles
With subfolders per layer, for example:
base directory/tiles/OpenCycleMap

- offline routing data
base directory/routing_data
With subfolders per routing data type, for example:
base directory/routing/monav
base directory/routing/routino
base directory/routing/navit

- vector map data
base directory/vector
With subfolders per vector data type, for example:
base directory/vector/osm_pbf
base directory/vector/kothic_sqlite

- POI
base directory/poi
With subfolders per poi database type, for example:
base directory/poi/osm_extracts
This directory is meant mostly for big POI extracts,
(all cities in on the world, all restaurants in Europe, etc.)
private POIs should be stored in an application specific folder.
On the other hand the base directory/poi folder might
be a god place for sharing Points Of Interest between applications.


Benefits

- applications that agree on a common format (web mercator tiles,
  OSM PBF/XML, routing routing database) can use the same data set
  (also opens the possibility to have separate data loaders and viewers)
- automatic discovery - applications can automatically detect know if any
  given uSD partition has map data they can use and also know that if a 
partition

  has a .maps folder, the folder can be used for data storage
- centralized map data management - if the map data is stored in a single
  location it is possible to easily check both total amount of space used
  and space usage per data type independent on data management
  capabilities in individual applications
- it makes it also possible to easily delete selected map data types
  without hunting for app specific data folders
- could be made Tracker-safe - most people probably don't want Tracker to
  crawl a couple thousand map tiles to their image gallery :)


Possible topics for further discussion

- .maps as base directory ?
The directory is marked as hidden and thus would not bother most
users during normal uSD usage, On the other hand users might
wonder about missing space. A visible map data base folder
(say just maps) could on the other hand be more easily deleted
by accident.

- who creates the base directory ?
An application needs to first create the base directory on the proper
partition, most probably based user input.

- sub folder standardization ?
How to map map data type, such as an individual tiled map layer,
to a subfolder name, so that multiple applications can use it.


Looking forward to your feedback! :)

Withe best wishes
Martin Kolman

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] [RFC] Well known map data path

[Martin Kolman]

18.3.2014 22:48, Alejandro Exojo:

El Tuesday 18 March 2014, Martin Kolman escribió:

This common location is the .maps directory in the MyDocs folder, giving
the /home/user/.maps path.

Are you aware that this is against what is already explained in the Harbour
FAQs? I have 60 files or directories directly under $HOME in my computer, and
is quite inelegant. At least now applications try to follow XDG
conventions/specifications and things are somewhat ordered under ~/.config.

Jolla wants to be able to tell how much space an application might be
consuming (and freeing that space upon application removal), so you should
take that into account too.

Please note that the section (Background) you are quoting is 
explaining how map data storage
is handled on Maemo 5/N900. Also it looks like I made a typo, it should 
have been:


/home/user/MyDocs/.maps
not
 /home/user/.maps
(this might in part have caused the confusion).

 My proposal as outlined in the next Proposal section is only 
targeted on external storage (currently the Jolla device uSD card), in 
internal storage applications should of course comply with the XDG 
guidelines to avoid chaos.

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] prefered way to build rpm package for a project written in python/pyotherside?

[Martin Kolman]

5.3.2014 22:13, Boris Pohler:

Hi,
I wrote my first little program using python/pyotherside. I develop
directly on the jolla-device (no sdk) and would like to build a rpm
package to distribute to openrepos (and later to harbour, if python is
accepted). What is the prefered (easiest) way?
Well, I'm for example using OBS to build packages for my 
Python/PyOtherSide based modRana application
(the modRana package available from OpenRepos since last week[2] was 
build on the Mer OBS)

and the other possibility is the already mentioned rmbuild utility.

Both boil down to basically one thing - you need source code archive 
(tarball) and metadata file (spec file).


For example, this is[3] my tarball  the (rather crazy) specfile for 
building the modRana package.


As you can see, the specfile just has some metadata like application  
author name, version,

names of dependencies and listing of files and where they should end.

So basically what you can do is take a specfile (the modRana one or some 
less crazy one), modify it
to describe your application and use it to build your own packages with 
OBS or the rpmbuild utility.


With best wishes
Martin Kolman

PS.: Official documentation/support for building Python applications for 
Sailfish would still be welcome. :)


[1] 
https://build.merproject.org/package/show?package=harbour-modranaproject=home%3AMartinK%3Asailfish%3Amodrana

[2] https://openrepos.net/content/martink/modrana-0
[3] 
https://build.merproject.org/package/files?package=harbour-modranaproject=home%3AMartinK%3Asailfish%3Amodrana




Boris

P.S.: My desktop-distribution is Archlinux.
  


___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Scriptlets in RPM hot allowed to Harbour

[Martin Kolman]

21.1.2014 21:34, Martin Grimme:



You can compare
those in their function to Maemo Extras and Maemo Extras Devel in the old N900
days.
Everybody could upload to Extras Devel, but to get stuff into Extras, it had
to pass a quarantine and a (IMHO slow and frustrating) QA phase.
Only Extras was pre-enabled on sales devices, and even for this, Nokia
had to be
convinced first, that apps reaching Extras are ready for regular users.

Just a slight correction. As far as I know, you can only upload source code
to Extras-Devel which is built by the Maemo Autobuilder and the 
resulting binary package
published. I'm quite sure you can't upload binary packages at all, at 
least I have not seen

any in all those years in Extras-Devel.

On the other hand both OpenRepos and Harbour currently only accept 
binary packages,

at least until the OpenRepos - OBS bridge is online.

So when we are doing comparisons, I would say Harbour is closer to the 
Ovi store, as available on Fremantle and Harmattan:

* binary only upload
* cross package dependencies not supported (bundle-all approach)
* IIRC, there were no limits on packaging scripts
* centralized mandatory QA with a multi-day QA period
(at least the Harbour QA seems to repply in a more comprehensible 
manner, unlike the sometimes very confusing responses of the late Ovi 
store QA drones)
* rules where the apps should store its file (data goes to /opt, 
deploying binaries to path not allowed, ...)

* mandatory major.minor.build numbering
* as Profilematic is in Ovi store, it looks like it was possible to 
install daemons and bind to events

* location was supported over QtMobility
* some semi-sane requirements for apps not to stop working due to upgrades
* also only one-way user-store feedback and comments
* unlike current Harbour, Ovi had a Web interface
* no Android apps, but flooded by automatically made RSS-reader apps :)
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Scriptlets in RPM hot allowed to Harbour

[Martin Kolman]

11.1.2014 11:43, Andrey Kozhevnikov:
you suggested to change /usr/share/appname/data folder permissions in 
post script, so that means no way to go to harbour for this application?


QA can check if post script doing some good job and allow it?

On 11.01.2014 16:41, Jonni Rainisto wrote:

because they are runned as root.

From: devel-boun...@lists.sailfishos.org 
[devel-boun...@lists.sailfishos.org] on behalf of Andrey Kozhevnikov 
[coderusin...@gmail.com]

Sent: Saturday, January 11, 2014 11:22 AM
To: Sailfish OS Developers
Subject: [SailfishDevel] Scriptlets in RPM hot allowed to Harbour

Why RPM scriptlets not allowed to harbour?
___
SailfishOS.org Devel mailing list
___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

This is a joke, right ?

Well there goes Harbour. Long live OpenRepos, the sane new main Sailfish 
application repository...

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Out of curiosity: why are you developing for SailfishOS?

[Martin Kolman]

Because it's there. ;-)

10.1.2014 11:26, Ruediger Gad:

Hi all,

just out of curiosity, I am asking why are you developing for SailfishOS
and, if yes, what is your motivation to push your apps to Harbour?
I don't want to spam the mailing list with such an off-topic discussion.
Hence, I created a thread at talk.maemo.org for this:
http://talk.maemo.org/showthread.php?p=1405346#post1405346

Excuse the cross post here but I think that this is the best channel to
reach people actually developing for SailfishOS.



BR,

Ruediger






___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] How to install user (controlled) data files for my app avoiding /usr/share

[Martin Kolman]

9.1.2014 23:27, Wim de Vries:

Thanks Thomas for the explanation.
Indeed, I think I will stick to a minimal persistent data set  to 
enable the user to play with.

For the open/free data I will have a look at SF.
The maps created by the user (with an accompanying  desktop 
application) will have to be copied to sailfish via USB to a dir in 
$XDG_DATA_HOME.
The good thing is that I am not in a hurry, don't expect many pilots 
with a Jolla for now :-)

And, in the long term ... A pilot Other Half!
Well, a TOH with barometer  a variometer application might be a nice 
combo for glider pilots. :)




r
wim

On 01/09/2014 01:50 PM, Thomas Perl wrote:

Hi,

On 09 Jan 2014, at 09:05, Wim de Vries wsvr...@xs4all.nl wrote:

I am converting my aircraft navigation app to Sailfish.
It comes (default) with OpenStreet based maps + 3D data files of 
Western Europe (in RPM).
Most users will use this map, but some users may use their home made 
maps (generated by a PC application).
In the latter case, the users will delete this W-Europe map (it 
takes up quite some disk space).

So far so good, but the installation/RPM is a problem:

Harbour says that I should install the app data (very much bytes for 
the W-Eu map) in /usr/share/$NAME and in the first run of the app, 
copy them to $XDG_CONFIG_HOME/$NAME.
But  now I am stuck with an enormous amount of (useless) data in 
/usr/share/$NAME that cannot be removed.


Any suggestions?
The “copy stuff to the home directory of the user” is only relevant 
if you want to e.g. ship default config files and install them to the 
config directory on first start (the suggestion was put in place when 
somebody wanted to install files to /home/nemo/.config/ in the RPM 
file, something that will also lead to unhappy people in case of 
package upgrades, and that was suggested as best practice if the code 
can’t deal with missing config files - which it ideally should ;)). 
For big files, obviously it doesn’t make sense to copy them to 
$XDG_CONFIG_HOME/$NAME. Instead, what you could do is install them to 
/usr/share/$NAME, and then just have a flag in $XDG_CONFIG_HOME/$NAME 
if the user wants to disable the system-wide data (of course, this 
doesn’t free the data, but in case hiding/not loading the data will 
improve e.g. the startup time or user experience, it could still make 
sense).


For data that the package manager installs, only the package manager 
should modify/remove the data. Making /usr/share/$NAME world-writable 
is not allowed per harbour rules, and for good reason - if the user 
would e.g. delete the pre-installed maps there, they would re-appear 
every time the app is upgraded, or if the user modifies the data 
there (or the app), these changes would be overwritten by a package 
upgrade.


Also, another thing: Having big pre-installed data in the app 
packaged (=inside the RPM) is bad, as it will require this data to be 
re-downloaded every time the package is installed, and (during 
installation time) will take up the space for the - temporarily 
downloaded - RPM and the extracted data (you will need ~ 400 MB free 
to extract a 200 MB RPM file with 200 MB of data inside, not taking 
into account compression and stuff).


So, you have an app plus some big data that probably doesn’t change 
as often as the code does (either it changes more often or it doesn’t 
change as often - the data doesn’t usually have anything to do with 
code updates to your app except if you happen to do some data format 
changes).


There are basically two options:
  1. Don’t ship any data with your application
 - Small download and upgrade size, no wasted space
 - For the “pre-packaged” maps, you could download them in the 
app on first start

  2. Ship data with your application, and don’t let the user delete it
 - No need to host any data packages
 - Package upgrades and first download will be unnecessarily large

I’d suggest you do variant 1: Users who have a good connection might 
not want/need to download much data upfront, they might just want to 
try out your app (=easier when it’s a smaller download) and only 
after they’ve tried and liked your app, they might go into the in-app 
menu and select something like “download pre-packaged maps”. As your 
data seems to be open in some sense, you might be able to either 
download it directly from the OSM servers, or you package it up and 
put it up on some hosting service (e.g. sourceforge.net works well 
for hosting such data downloads, including mirroring - but any other 
service or your own web server would work just as well).


If you really do want to ship the data with your package, it should 
not be possible to delete it, only possibly hide it from the UI of 
the application via a setting that is stored in 
$XDG_CONFIG_HOME/$NAME. By the way, all the data that you download 
should go into $XDG_DATA_HOME, not $XDG_CONFIG_HOME (as the name 
suggests — this will allow backup and cleanup applications in the 
future to e.g. backup 

Re: [SailfishDevel] Statically link python

[Martin Kolman]

29.12.2013 00:17, Benoit:

Hi all !

As you probably know dynamic linking to python isn t yet allowed in harbour.

So, maybe someone can point me to some docs for including a static libs in 
package in SDK (this will also help me for an other project).

Thanks a lot
Or maybe just bundle all the relevant Python SOs  stdlib modules in the 
package ? Setting LD_LIBRARY_PATH  PYTHONPATH  co in a startup script 
should do the trick. :)

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] [SPAM] Re: Does Sailfish support PyQt5?

[Martin Kolman]

26.12.2013 23:34, Mikael Hermansson:


Its not my opinion it's a fact why should a new platform depend on 
deprecated libs or language versions when we know it very soon will 
disappear even from upstream projects? And dists?


Its only leads to maintanance hell. And when it disappear developers 
and endusers gets angry because apps not work.


AFAIK Jolla don't recommend python2 even if it still exists in MeR or 
the repos it may very well dissapear sooner or later.


So if you really want PyQT you better depend on python3 because that 
IS the future.



I think PyQt5 supports Python 3 and can be built against it just fine.


Also think about the endusers, I know very well that its fun to play 
with every libs and possible combination but still can't hold every 
possible combination and endusers are probadly not intrested to 
install to many thirdparty repositorys just to get one application 
work. Right now it already seems to be an issues with all those 
thirdparty dropbox links releases latest days...


Regards

Mikael

On Thursday 26 December 2013 20.15.19 Jens Persson wrote:

 Well, that's your opinion. But today it's Python2 that is default in

 Sailfish and not three and that's why I built PyQt with two. Afaik all

 Python modules currently available as default (dev mode enabled) are 
built


 with Python2.



 Greets Jens



 On Thu, Dec 26, 2013 at 8:03 PM, Mikael Hermansson m...@7b4.se wrote:

  AFAIK python is NOT installed from scratch in sf. also if python 
will be


  supported it will be python3 as thomas already has said.

 

  Thats the way to go. Python 2 should be seen as deprecated on new

  platforms IMHO...

 

  Regards

 

  Mikael

 

  Thu Dec 26 2013 19:00:35 GMT+0100 (CET) skrev Jens Persson:

  PyQt works very well on the Jolla phone and you can get it from

  Openrepos.

  It should support the whole Qt C++ API except for deprecated 
modules. As


  Sailfish is using Python2 by default I've built it with that. Porting

  from

  Pyside to PyQt is very easy and takes only a few hours for a 
small app


  and you can publish them on Openrepos as Harbour does not support 
PyQt


  and

  maybe never will. Just remember that PyQt is GPLv3 so you must 
use that


  license or pay for a commercial license from Riverbankcomputing. IMHO

  this

  is not a big problem as most Python apps are opensource and you 
better


  stick with native code for closed source anyway.

  

  Greets Jens

  

  On Sun, Dec 1, 2013 at 3:27 PM, Ye Zetao kongkong...@gmail.com 
wrote:


   Hello,I am a developer of python and I know that Sailfish 
support Qt


 

  with

 

   C++, but I am not familiar with C++,So I want to know that if 
Sailfish


   support PyQt5 ? Thanks :)

  

   ___

   SailfishOS.org Devel mailing list

 

  --

  Skickat från min Jolla

  ___

  SailfishOS.org Devel mailing list

--

Skickat från Lenovo Thinkpad X230 running Kubuntu desktop



___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Jolla owner - day 1

[Martin Kolman]

21.12.2013 20:44, Thomas Tanghus:

- Twitter: Says »Creating account« then nothing. Doesn't ask for credentials.

- XMPP: Silently fails on certificate error. Doesn't show up as an option in
messages.
I can confirm having both of those issues. But the weird thing is that 
when a friend
was showing me his Jolla, I'm quite sure he had Twitter account showing 
up on the

notification screen  stuff from Twitter on it.
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Jolla owner - day 1

[Martin Kolman]

21.12.2013 22:10, Thomas Tanghus:

On Saturday 21 December 2013 22:05 Markus Svensson wrote:

Hi guys,

I also received my device yesterday. I was able to both register in the
Yandex store as well as register my Google account. I did perform both
activities before applying the OTA software update, IIRC.

That may be of importance. I did the update right away before anything else.

Did the same thing.
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] SailfishOS (Dutch) translations

[Martin Kolman]

16.12.2013 10:25, Reto Zingg:

Hi,

On 15.12.2013 13:28, Wim de Vries wrote:

On 12/15/2013 11:45 AM, Javier Ferreira wrote:


Waiting for the portuguese

Em 15/12/2013 07:41, Jarno jarno.de@gmail.com
mailto:jarno.de@gmail.com escreveu:

Hi,

I was wondering if the current SailfishOS UI is ready to be
translated to more languages. As of yesterday the Dutch Sailors
are receiving their phones and most of them would love to see a
Dutch UI. And even better, some of them already said they are
willing to help translate. Some of them have experience with
translating Meego apps and at least two have worked on translating
Plone CMS (including me).




So, plenty of people eager to make this happen.


meeto


Nice to hear that you guys are eager to help. Unfortunatelly a system 
for that is not yet in place. But we are looking into that and have 
already some ideas. But we can't give you any ETA at that moment.


So please stay tuned and looking forward for more cocreation
Reto
What about Transifex[1]? It seems to be the de-facto standard for 
community translations at the moment.
There are also already other distributions using it for all their 
translation work, such as Fedora[2].


[1] https://www.transifex.com/
[2] https://fedora.transifex.com/
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Harbour news

[Martin Kolman]

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] working on apps?

[Martin Kolman]

14.12.2013 11:41, AL13N:

if there are people who are working on apps, and want to let it know, so
that no other devs will waste time making the same apps, you can add these
here:

http://elinux.org/Jolla

in the appriopriate section.

Thanks!

___
SailfishOS.org Devel mailing list

I'm porting the modRana flexible navigation system[1][2] to Sailfish
and I plan to also port the Mieru offline manga and comic book 
reader[3][4]. :)


Best wishes
Martin Kolman

[1] modRana source code: https://github.com/M4rtinK/modrana/
[2] modRana discussion thread: http://talk.maemo.org/showthread.php?t=58861
[3] Mieru source code: https://github.com/M4rtinK/Mieru
[4] Mieru discussion thread: http://talk.maemo.org/showthread.php?t=73907


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Qt5.2/NFC API in sailfishos

[Martin Kolman]

2.12.2013 11:35, Robin Burchell:

But what got me dissapointed was that the new Qt NFC API module is only
supported on Blackberry?

So what is the state of NFC API on sailfishos? Will it use it? or is there some
kind of NFC API?

At this stage, NFC is reserved for use with the other half. I don’t know of any 
future plans to change that at this time, but you never know…

Well in my naive understanding, could one of these two work:

* lets assume that NFC can detect multiple tags/NFC devices at once (can 
it ?) and all the other halves surely have some sort of unique id (so 
that different ambiances can be detected) that all have a common prefix 
(so that the device can distinguish between OH and another NFC device
- in this case, the device can just filter out the NFC chip on the OH 
when working in normal NFC mode (pairing, contact transfer, etc.)


* lets assume the NFC-bearing OH can be removed and an NFC-less OH installed
- the chip can detect the NFC tag in the OH, so it should detect normal 
NFC devices just fine if a NFC-less OH is installed


So that are my two €-cents. :)
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Jolla Harbour and Jolla Store

[Martin Kolman]

12.11.2013 17:57, David Greaves:

Last I heard the plan was to allow the Mer OBS to build SailfishOS rpms.

Sounds great, fingers crossed! :)


David

On 12/11/13 15:18, Marcin M. wrote:

Hi,

Will there be OBS for Sailfish available?

Regards,
--
Marcin


2013/11/12 Karl Granström karl.granst...@jolla.com
mailto:karl.granst...@jolla.com

 Ahoy all,

 We managed to fix all issues with the Harbour and it is open again for all
 of you to dock there harbour.jolla.com http://harbour.jolla.com.

 Few updates:
 We currently support only 3 screenshots but will improve this so that in 
the
 future you can upload more.
 The optional Cover image dimensions are 540x270 px

 IMPORTANT NOTICE:
 When changing the build target from i486 to ARM or vice versa, be sure to
 clean your project before building it again.If you don't do this you might
 end up deploying wrong architecture binaries of your application. Cleaning
 is done by selecting  Build-Clean project project or Build-Clean 
All
 from Qt Creator.

 Also please note that Qt Creator shadow building does not work for
 SailfishOS - yet.

 If you encounter any issues, please contact us by email,
 developer-c...@jolla.com mailto:developer-c...@jolla.com, or report them
 to the Sailfish developers mailing list at devel at lists.sailfishos.org
 http://lists.sailfishos.org.

 Br,

 The Jolla Store Team

 On 06 Nov 2013, at 13:06, Karl Granström karl.granst...@jolla.com
 mailto:karl.granst...@jolla.com wrote:

  Ahoy all,
 
  Today we're launching Jolla Harbour harbour.jolla.com
 http://harbour.jolla.com, the portal for submitting applications to the
 Jolla Store.
  You can submit and manage your applications. Consumers will be able to
 install them directly from their Jolla phones.
 
  Here are some details about Jolla Harbour:
 
  Joining and logging into Jolla Harbour:
  Joining is free! You can create a Jolla account from the Jolla Harbour
 landing page (harbour.jolla.com http://harbour.jolla.com) or if you have
 pre-ordered your Jolla phone, you have everything you need to get started.
 To manage your account details, please visit account.jolla.com
 http://account.jolla.com.
 
  Support for Sailfish and Android™ applications:
  You can submit both Sailfish and Android™ applications to Jolla Harbour.
 The submission process is the same.
 
  Start with free applications:
  At launch, the Jolla Harbour and Jolla Store will support only free
 applications. We are working hard to enable payment solutions and we will
 keep you posted about these capabilities as they develop.
 
  Binary package naming:
  You will receive naming guidelines when you upload the binary package to
 Jolla Harbour. You can also find guidelines on versioning at 
http://semver.org.
 
  Preparing your metadata:
  Jolla Harbour needs to know a few things about your app:
  - An app icon for the Store  (86x86px, png) (Current SDK supports 90x90px
 images; more details to follow soon)
  - 1-3 screenshots (540x960px, png or jpg)
  - An optional Cover image for your Store page (516x252px, png or jpg)
 
  Submission process:
  To submit your application to Jolla Harbour, fill in the metadata for it
 and upload the binary and required images. After you have submitted your
 app, Jolla will start Quality Assurance testing.
 
  Quality Assurance testing:
  Jolla will perform QA testing on your applications on real Jolla devices.
 We will get back to you with feedback on your app within a few days. You
 will be notified on the QA results via the email address you have 
registered
 to your Jolla account.
 
 
  If you encounter any issues, please contact us by email,
 developer-c...@jolla.com mailto:developer-c...@jolla.com, or report them
 to the Sailfish developers mailing list at devel at lists.sailfishos.org
 http://lists.sailfishos.org.
 
  Happy hacking!
  The Jolla Store Team
 
 
  ___
  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] Jolla Harbour and Jolla Store

[martin . kolman]

The same question - those two seem to be a direct contradiction.

BTW another counterexample: On BB10 you can't even read the stdout log of 
signed apps, making debuging of signed applications very difficult.


Dne 07.11.2013 21:09 napsal uživatel Attila Csipa:

On 07-Nov-13 01:42, Jonni Rainisto wrote:
 We are working hard on adding copy protection


In the context of Will you support DRM? No in your FAQ, and having an 
open, hackable device environment, please do elaborate. I sincerely hope
that Jolla has learned from the Aegis experience and general success
of copy-protection schemes on other platforms.


Best regards,
Attila

___

SailfishOS.org Devel mailing list



___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Jolla Harbour and Jolla Store

[Martin Kolman]

6.11.2013 22:33, Roberto Colistete Jr.:
snip:
 And Mer/Nemo Mobile/Sailfish don't use .deb, but .rpm packages.
 ___
 SailfishOS.org Devel mailing list
Yep, and as anyone can easily try, zypper on Nemo is blazing fast.

And regarding repository size, you install something with yum on Fedora
(which has a bazillion of packages the repository) - it is realy fast.
And it should be even faster once the libsolv based DNF[1] replaces yum 
as a default.


Fedora also uses DeltaRPM/Presto[2] for updates, so only the differences
are transferred when package is updated, drastically cutting down the amount
of transferred data.
BTW, this alone could be a nice addition due to the limited amount of
Internet connectivity often available on mobile devices.

Also one thing that I think has not yet been mentioned:
* security vulnerabilities in bundled libraries

If a vulnerability in a library is found:
* on a system with proper package management, you update the library and all
  applications using it are automatically immune
* on a system where applications need to bundle libraries, all applications
  bundling the given library are vulnerable until their authors 
manually update them
  (and there is also no 100% sure way to check what libraries are being 
bundled

  and therefore which applications are vulnerable)


[1] https://fedoraproject.org/wiki/Features/DNF
[2] http://fedoraproject.org/wiki/Features/Presto
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Innovative app store. Or just a traditional one

[Martin Kolman]

I'll chip in with my idea/RFE:

Built-in donation support.

* usecase
- the app is free
- but there is a donation button in the store interface
- users can click it to donate to the developer

As it is part of the store interface, it can use the same payment mechanism
as paid apps, making the donation procedure as painless as possible and 
thus more likely. :)

In-application donation buttons need to use external payment methods,
that have many drawbacks such as:
- being evil (PayPal)
- not widely used (Flattr)
- experimental (Bitcoin)
- generally not being available in many countries

* example of store having something like this - Mozilla addons
https://addons.mozilla.org/en-US/firefox/

Each extension can have a Contribute button, see the Firebug extension 
as an example:

https://addons.mozilla.org/en-US/firefox/addon/firebug/

* could be a nice first :)

I don't know about any current mobile store having built-it donation 
support,

so it could be another nice first for Jolla. :)


5.11.2013 22:04, Artem Marchenko:

Hi All

Phone is going to be in sales soon, app store is going to accompany 
it. What would you as app developer appreciate in the app phone?


Is there anything on top of just buy an app or just buy this game 
upgrade in-app what could be an important feature for you? Any 
disruptive ideas?



As for me, I'd appreciate a couple of options:

1. Built-in try-before-you-buy.
To get rid of free/paid app pairs you see in the other app platforms. 
If developer doesn't mind, user should just be able to use app for 
free for some 7 or 30 days. After that - only after payment or with 
some features downgraded.


2. Built-in subscriptions, especially for micro-sums
Subscription-based schemes motivate developers to improve apps all the 
time while worrying less about hit-or-miss situation, so it would be 
cool if app store supported it.


I seriously would think even of small prices as just $0.95 a year, but 
it has to be charged on a monthly basis yet nobody is going to bug 
users with 10 cents monthly paid upgrade.


It would be great if app store supported such subscription methods 
natively. And certainly it could be seamlessly combined with 
try-before-you-buy so that first month is completely free.


What do you think?

Cheers,
Artem.

P.S.
I am not working for Jolla, just a random developer interested in the 
topic.


--
Artem Marchenko
http://agilesoftwaredevelopment.com
http://twitter.com/AgileArtem


___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] File chooser

[Martin Kolman]

4.11.2013 02:10, Artem Marchenko:
I'd appreciate some UI guidelines voice from Jolla here (I can 
understands they might have not thought of this use case before, well, 
it's time for it then :)).


Looking at iOS and Android, it might be not a bad idea to have a phone 
UI without an explicit file interface at all. Hackers won't appreciate 
it, but they have terminal anyway and, well, for them you can create a 
custom File Open dialog.


Regular users might appreciate a photo choosing dialog guaranteed to 
include all device photos more.
Yeah, I think those two are not mutually exclusive  doable. IIRC there 
should be Tracker, so it should be possible to get all photos or any 
other categories of files Tracker can discern (all audio files, all txt 
files, all PDFs).
But on the other hand, some applications just won't do without a 
standard file-chooser, like a text editor, offline comic book reader, an 
image editor. At least without getting and putting the files on a global 
file heap, making finding stuff difficult.
Of course a lot can be done with tags and semantic stuff (where did the 
file come from, what app made it), but as shown by the KDE  GNOME 
projects (Nepomuk, Akonadi, Tracker, etc.) it is not easy to get right. 
Just having a simple time-proven file open dialog is IMHO a much 
simpler, easier  safer solution.


BTW, Android and to a lesser degree Harmattan could be used as a bad 
example of what happens if there is no default file dialog - every app 
that needs it would implement their own, all looking different (and not 
native) and every one of them with their own set of drawbacks.


Cheers,
Artem.



On Sun, Nov 3, 2013 at 11:02 PM, Martin Kolman 
martin.kol...@gmail.com mailto:martin.kol...@gmail.com wrote:


1.11.2013 22:16, Janne Pulkkinen:

Sailfish would benefit from having a default file/directory
chooser instead of having different implementations made by
different developers which would only make the OS appear
inconsistent for the average user.

Just putting this out there, because I would really like to see
this implemented in the SDK.


2013/11/1 Damien Caliste dcali...@free.fr mailto:dcali...@free.fr

Hello,

On Fri Nov  1 08:54:03 2013 kher...@khertan.net
mailto:kher...@khertan.net wrote:
 For the file selector, it should not be difficult to make
one with a
 SilicaListView, and the qmldir extension.
Ok, I'm new to QML, I didn't know about qmldir. I'll give a
look. But I was hopping something common to avoid discrepency
on the platform. Thanks for the info.

 For notification, i ve made a something similar but more
simple to the
 Harmattan InfoBanner for ownNotes :
 http://khertan.net/blog/silica_infobanner
Great. I'll give a look also waiting for something from Jolla
if any. Thanks.

Regards,

Damien.
___
SailfishOS.org Devel mailing list




___
SailfishOS.org Devel mailing list

What about the FileDialog component[1] introduced in Qt 5.1 ?
The documentation says that it will use a native platform
file-open dialog if available,
so maybe just make a silica themed file open dialog and show it
once the FileDialog component is used ?

[1]

http://qt-project.org/doc/qt-5.1/qtquickdialogs/qml-qtquick-dialogs1-filedialog.html

___
SailfishOS.org Devel mailing list




--
Artem Marchenko
http://agilesoftwaredevelopment.com
http://twitter.com/AgileArtem


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Sailfish User Interface: Tabs

[Martin Kolman]

12.10.2013 17:51, Mikael Hermansson:

And trying to make good UI that works on all platforms is just wrong way of
thinking IMHO. Its better split UI part from the logic and share as much as
possible between the platforms but still use native ui for the platform
used.
While this works quite nicely for simple one-off applications that don't 
change, it gets tedious really
fast for a continuously developed application if you have to keep half a 
dozen different GUIs in sync feature wise.

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Python Qt5 (PyOtherSide / PyQt)

[Martin Kolman]

30.9.2013 16:15, Roberto Colistete Jr.:
About PyQt5 on Mer/Sailfish, I think it is worth to : help porting 
many PyQt4/PyQt5 softwares from PC and Maemo 4  5; have all Qt5 
functions in Python. More programming options - more softwares on 
Mer/Sailfish. 8-)
I would second that. While I think at least in my case, PyOtherSide  
Python backend should be able to cover all what is needed for my modRana 
and Mieru Sailfish ports, I think there might be some use-cases where 
all the various Qt class wrappings provided by PyQt might be useful. 
Stuff like XML/JSON parsing, network access manager, Qt resources, 
QObject, signals  slots, QWidget, QThread, QtSerialPort, etc.

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] QtMobility and Python bindings

[Martin Kolman]

18.7.2013 08:12, FIlip Kłębczyk:
Martin, I don't believe it will be left that way till phone launch. 
Somehow I have a feeling that someone, maybe even from Jolla ;) will 
help create PySide Qt5 bindings.


Regards,
Filip
Indeed, the news from THP look good. I've heard about PyOtherSide 
earlier, but it looked like a very limited proof of concept. Now it 
looks quite a bit more real. :)


Also the points he makes[1] are very good - most Python  QML 
applications use very little of the Qt machinery, but the the bindings 
normally bind it all, leading to long startup time  big size of the 
bindings (making things worse on platforms where all additional stuff 
needs to be bundled, such as on Android or BB10). I actually have a 
policy of sort when working on my applications, to place as much 
functionality as possible to the GUI  platform independent Python core. 
The GUI/s should be just a thin layer visualizing the data models from 
the core to the user. PyOtherSide as described so far seems to be a 
perfect fit in this regard. :)


In short what such a GUI layer needs:
* sending data (numbers, strings, etc.) from Python to QML and from QML 
to Python
* some sort of signals to notify the GUI about events in Python 
(download finished) and Python about events in QML (search button clicked)
* loading images from Python to QML - from files  file-like objects 
residing in memory
* shared data models - this is kinda optional, as it could be hacked 
together from data passing and signals, but having it built in would be 
kinda nice


I guess that's basically it - once this work in some form, we are good 
to go. :)


One issue could be vector drawing, which is IIRC currently handled by 
sublassing the declarative item and drawing to it with QPainter. No sure 
how this would work with the PyOtherSide asynchronous mode of operation. 
But there should be some canvas like drawing mechanism in QtQuick 2.0 
and worst case, one can still just draw PNGs to file like objects with 
pycairo and pass it to QML. :)


BTW, PyOtherSide reminds me a bit about the Tart project[3][4] started 
by Peter Hansen to provide bindings for Cascades on BB10, not sure if it 
the project is still active though.


Best wishes
Martin

[1] https://twitter.com/thp4/status/357849906750316544
[2] 
http://thpmaemo.blogspot.cz/2013/07/the-way-forward-with-python-on-qt-5.html

[3] http://hg.microcode.ca/blackberry-py/src
[4] http://peterhansen.ca/blog/blackberry-tart-preview.html



___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] QtMobility and Python bindings

[Martin Kolman]

17.7.2013 16:54, Osmo Salomaa:

Hello friends,

I have taken a look at the Sailfish SDK with the intent of investigating
prospects of developing applications in Python. I didn't manage to find
the Python bindings for QtMobility using zypper and the default SDK
repositories. I also tried to find them for my desktop system running
Debian unstable, but it seems Debian removed pyside-mobility a year ago
due to being dead upstream and failing to build from source [1].

So, what's the status of QtMobility and Python? Has someone picked up
maintainership? Will it be included in a newer version of the Sailfish
SDK? Is there a development repository where I could find this kind of
stuff (like extras-devel was at Maemo)?

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671356

The pyside-qtmobility build[1] I have in home:MartinK:nemo project or 
Mer OBS worked last time I've tried it.
By worked, I mean at least the screen blanking control worked and I 
couldn't really test the rest due to missing support for GPS in Nemo.
If it works for you, I guess the package could be submitted to one of 
the Nemo or Mer repositories.


There is also a possible workaround/dirty-hack for missing 
python-qtmobility bindings - some of the QtMobility APIs are also 
available to QML. It is possible to wrap the API in QML with a custom 
element and then from Python grab this element from the QML context and 
use it. This is how AGTL[2] was using the GPS last time I looked at it's 
source code.


Still there might be some near future hurdles for Sailfish application 
development with Python. Jolla announced a few days ago that the first 
Sailfish running device will be running Wayland and Qt5 only[3][4], 
dropping X11 and with it Qt4 support. This is unfortunately quite an 
issue for Python application development, as there are currently no 
Python bindings supporting Qt5  QtQuick 1.0 or 2.0[5]. Also, all Python 
applications that were already ported to Sailfish using the current SDK 
won't run in their current form, leading to some wasted effort.


Hopefully, the situation might improve on PyQt get's QtQuick 2.0 support 
(no timeline for that just yet though), but PyQt packaging and PySide - 
PyQt conversion would still be needed. Also in contrast to the LGPL 
PySide, PyQt is GPL only, which might be an issue to some developers.


In comparison, while there has been some recent activity in the PySide 
project, it has been so far limited to bugfixing and work on Qt5 support 
has not yet been started.



[1] 
https://build.merproject.org/package/show?package=python-qtmobilityproject=home%3AMartinK%3Anemo

[2] https://github.com/webhamster/advancedcaching
[3] https://twitter.com/cybette/status/356033983588478976
[4] https://twitter.com/JollaHQ/status/356061760089890816
[5] 
http://pyqt.sourceforge.net/Docs/PyQt5/pyqt4_differences.html#qtdeclarative-module

___
SailfishOS.org Devel mailing list