[SailfishDevel] FOSDEM Community follow-up - open source app community

[Thomas B. Rücker]

My question has been lingering for a while. (
https://together.jolla.com/question/13605/visible-open-source-app-community-supported-by-jolla/
)

But during FOSDEM we had a Sailfish/Jolla Community Round-Table (
https://together.jolla.com/question/11303/are-you-going-to-fosdem-2014-irl-floss-meeting-in-belgium/?answer=13864#post-id-13864
). This topic was brought up and seems Sailors are committed to address
this with pushing forward towards a clean open source app repository
with community QA and easy on-device access after enabling developer mode.

This would provide something like Maemo Extras and would be community
QA'd to ensure the apps don't pose major problems when installed. On the
other hand it would provide an easy middle ground for apps that don't
fit into harbour for various reasons (API calls, dependencies, etc.).

It will be backed by an OBS project on Mer community OBS, which has
Sailfish targets. OBS has come a very long way since we've seen it
first. I've personally had several apps build out of the box by just
_clicking_:
* create package
* source provision through tar_git
If the app builds on a clean SDK, then it's highly likely to build out
of the box also on OBS.

You may now say "what about openrepos?". They have chosen to be a site
for one-click RPM hosting repositories with no QA. Despite their best
efforts this approach has led to significant problems. Also it does
binary only uploads and thus non-free/closed applications and no
traceable chain from source to binary.
That said, if the openrepos client (warehouse) passes community QA it
will for sure be included in the community repository. Thus allowing
users to install it easily, if they so wish. We're not hostile towards
it, it just doesn't offer the level of trust to be a viable avenue for a
default community repository.

This is a PERSONAL summary of MY recollection of the FOSDEM discussion
on this topic. I hope that Jolla will now finally back this up and we
will see Sailors working towards this.

For those who already want to get started, there is a SailfishOS target
on OBS and a community repository called "Chum" where applications will
be visible in the future.
https://build.merproject.org/project/subprojects?project=sailfishos

Cheers

Thomas
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] When does Jolla give us an API?

[itviewer]

+11

From: Luciano Montanaro
Date: 2014-02-04 01:10
To: Sailfish OS Developers
CC: David Greaves
Subject: Re: [SailfishDevel] When does Jolla give us an API?
Hi everybody,

I too find documentation a bit missing...
But it is not much about APIs, but system level documentation.
Qt documentation is good, at least for the parts that are still
actively maintained.

But SailfishOS uses Qt, on top of wayland, systemd, pulse,gstreamer
and telepathy, and a bunch of other services.

Open source package documentation can be very good, or completely missing.

Moreover, to achjeve the same thing I may use a Qt based API, or, say,
DBUS messages.

So I think that more than the APIs, it is the list of "allowed" or
preferred services that is needed.

SailfishOS as a Linux distribution is quite modern, and it would help
to know more about its plumbing.

Just my 2 cents.

Best regards,

Luciano

On Mon, Feb 3, 2014 at 5:59 PM,   wrote:
> Hi all
>
> my experience is that are a vast amount of apis out there: There is all the
> Qt stuff, the Qt add-ons, Nemo packages, and lower-level stuff like
> telepathy and GST. The problem is not the lack of APIs, but the choice of
> APIs. Which is the best one to use?.
>
> Then if you hit on a likely API, and find some good examples on the
> interweb, then it is not sure that that API will fully work on the Jolla
> (although this is likely to improve with every update as the Jolla matures).
>
> And if the chosen API works from a technical point of view, then that does
> not mean that harbour will permit it ... although this too should improve
> with time.
>
> On the whole I have found the Qt documentation to be very good. Where things
> get a bit shaky is using esoteric things like gaining device resource
> permissions (e.g permission to use the LED, or to access the phones
> contacts). For this sort of thing I often have to resort to the source code
> (which at work we call the ultimate documentation .8-) )
>
> mfg
>
> Chris
>
> Zitat von "David Greaves" :
>
>
>> On 03/02/14 15:29, Putze Sven wrote:
>>>
>>> Hi there,
>>>
>>> during Fosdem I spoke to some people about this, even to Carsten Munk
>>> from
>>> Jolla itself (not in the depth and detail of this mail, I must admit) and
>>> he
>>> suggested to write this in the mailing list, so those of Jolla who should
>>> be
>>> concerned have a chance to answer this question and I really would like
>>> to
>>> hear some official statements here.
>>
>>
>> Did you manage to get to the round-table event? - we spent a fair bit of
>> time
>> talking about APIs there; we also openly discussed the issues we face.
>>
>> I know that the community people there wanted to continue the discussion.
>>
>>> What does a developer need to write quality apps? An API and a
>>> documentation
>>> of such.
>>>
>>> So far there is a quite limited API available and therefore we don't see
>>> too
>>> many apps out there. How will you write a sophisticated app, if the API
>>> is
>>> not available or it is not allowed to use or is only known to those with
>>> Maemo/Meego history?
>>
>>
>> A quick response: we support the Qt API and rather than developing our own
>> proprietary one we're working hard to support the open one as it grows.
>>
>> The Qt documentation is extensive and superb :)
>> Using it in Sailfish Silica apps is less well documented but is improving
>> (and
>> honestly is mainly a tutorial issue for new developers - not an API docs
>> issue).
>>
>> Yes there are some APIs in the mobile space that are not part of the Qt
>> release
>> yet - Qt 5.2 will introduce more.
>>
>> David
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>
>
>
> ___
> SailfishOS.org Devel mailing list



-- 
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams
___
SailfishOS.org Devel mailing list___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Preventing deep sleep for a few seconds?

[Ove Kåven]

Den 03. feb. 2014 09:04, skrev Thomas Perl:

On 01 Feb 2014, at 21:32, Ove Kåven  wrote:

If a synchronization starts with the screen off, there's a chance that the phone enters 
"deep suspend" during the synchronization. If so, the other side might time out 
and the sync will fail.

So I want prevent the CPU from suspending before the synchronization is 
complete, which might take a few seconds (and there might not be network 
activity all the time while it's running). I've read that to get periodic 
wakeups, you could use libiphb or maybe timed, but what's the recommended way 
to temporarily prevent suspending completely for a few seconds?


You can talk to MCE via the system D-Bus, this is quite low-level, but works 
already:

https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329


Ah, thank you. I'll try this next time I get time for hacking on this.

But for scheduled wakeups (say I want the next synchronization to occur 
after 6 hours), I suppose the best option is to use "timed"?


(Then again, maybe that won't be of much use anyway, as the internet 
connection might be a problem if the phone has been suspended...)


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Recommended way to populate a LocalStorageDB from an external source

[Chris Walker]

On Mon, 03 Feb 2014 19:20:33 +0100
christopher.l...@thurweb.ch wrote:

> Hi All
> 
[snip]> 
> But I was never happy with that solution, and it now seems to me
> that a Qt Desktop app would be much better suited to configuring /  
> populating the DB. (more screen, better keyboard etc.).



> But exactly how should this work? I see several possibilities, all  
> with pros and cons.
 
> a) The Desktop app creates a LocalStorageDB, and the entire DB is  
> transferred to the Jolla. This means that Landed would have to
> deploy the DB on a file level, then access it via the LocalStorage
> api as normal.



> b) The Desktop app dumps a human readable exchange file (csv, xml,  
> json) which is picked up by Landed, parsed and converted to SQL  
> INSERTS then called via the LocalStorage API

> At the moment I favour option b) as the most likely to work and be  
> accepted, with option d) as the wildcard probably wont't work, but  
> might turn out to be the easy option.
> 
> Thanks in advance for your thoughts,

One question first. Are you intending to do the swap of files at home?
If so, why not fire up some sort of server on the home machine which,
when you fire up the app on the phone, is accessed by the app which
then proceeds to download the latest version of the database. You just
need to set up a procedure to make sure you're not going to overwrite
the 'father' generation of the database with the 'son' version, or even
worse the 'grandfather' version (that assumes that you have three
versions).

Another option is a dropbox client on the phone - I think one is
already available.

How about a line in the SQL file which has a creation date? That way
you easily run a check from the code on both the desktop app and the
phone to make absolutely certain that the version of the db you're
using is the latest all-singing, all-dancing version.

I personally wouldn't be doing all the export/import stuff. That seems
prone to errors/corruption IMHO.

Just my two pennies worth.

CDW (not Chris to avoid confusion ;-))
___
SailfishOS.org Devel mailing list

[SailfishDevel] Recommended way to populate a LocalStorageDB from an external source

[christopher . lamb]

Hi All

An architectural question: What is the the recommended approach (and  
harbour friendly way) to populate a LocalStorageDB on the Jolla with  
data from an external source?


Some background to the question:

My app Landed depends on a LocalStorageDB. It was always clear to me  
that Landed would be a readonly client of the DB, and the business of  
populating the DB would fall to "something else". Until recently that  
something else was a companion app LandedSettings.


But I was never happy with that solution, and it now seems to me that  
a Qt Desktop app would be much better suited to configuring /  
populating the DB. (more screen, better keyboard etc.).


This raises the question: How best to transfer the data populated in  
the Desktop app to the DB on the Jolla?


The Jolla's Documents folder (or a sub directory thereof) could  
clearly be used as as staging area. This is the approach that Wim  
takes with his Harbour-approved Checklists app.


But exactly how should this work? I see several possibilities, all  
with pros and cons.


a) The Desktop app creates a LocalStorageDB, and the entire DB is  
transferred to the Jolla. This means that Landed would have to deploy  
the DB on a file level, then access it via the LocalStorage api as  
normal.


b) The Desktop app dumps a human readable exchange file (csv, xml,  
json) which is picked up by Landed, parsed and converted to SQL  
INSERTS then called via the LocalStorage API


c) The Desktop app dumps an SQL script (a list of INSERT INTO  
statements) which Landed then executes


d) The Desktop app dumps an SQL script in the form of a javascript  
file, which is then dynamically loaded by Landed using dynamic QML


e) something I have not thought of ...

As further background, I tend to favour QML over C++, but use the  
latter where necessary (and am beginning to feel uncomfortably  
comfortable in that language ...).


I am aware that for any kind of file manipulation from QML I will  
probably have to resort to a C++ plugin. (Even this  
http://www.developer.nokia.com/community/wiki/Reading_and_writing_files_in_QML  
example from Nokia which sets out to provide file access without a  
plugin describes an implementation that is to my mind a c++ plugin!)


At the moment I favour option b) as the most likely to work and be  
accepted, with option d) as the wildcard probably wont't work, but  
might turn out to be the easy option.


Thanks in advance for your thoughts,

Chris






___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] SDK update

[Juha Kallioinen]

On 02.02.2014 21:44, Dmitry wrote:

Hi.

I have Mer VM and emulator version 2013.10.18-0 installed on Windows,
will VM disk image will be overwriten during update to 2013.12.10-1 
and i loose everything installed in VM?




Hi Dmitry,

yes that is how the update is done at the moment. Same goes for the 
Emulator.


If you have done any configuration, added extra repositories or 
installed new packages to the MerSDK build engine, build targets or the 
Emulator, all those will be lost.


Best regards,
 Juha
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] When does Jolla give us an API?

[Luciano Montanaro]

Hi everybody,

I too find documentation a bit missing...
But it is not much about APIs, but system level documentation.
Qt documentation is good, at least for the parts that are still
actively maintained.

But SailfishOS uses Qt, on top of wayland, systemd, pulse,gstreamer
and telepathy, and a bunch of other services.

Open source package documentation can be very good, or completely missing.

Moreover, to achjeve the same thing I may use a Qt based API, or, say,
DBUS messages.

So I think that more than the APIs, it is the list of "allowed" or
preferred services that is needed.

SailfishOS as a Linux distribution is quite modern, and it would help
to know more about its plumbing.

Just my 2 cents.

Best regards,

Luciano

On Mon, Feb 3, 2014 at 5:59 PM,   wrote:
> Hi all
>
> my experience is that are a vast amount of apis out there: There is all the
> Qt stuff, the Qt add-ons, Nemo packages, and lower-level stuff like
> telepathy and GST. The problem is not the lack of APIs, but the choice of
> APIs. Which is the best one to use?.
>
> Then if you hit on a likely API, and find some good examples on the
> interweb, then it is not sure that that API will fully work on the Jolla
> (although this is likely to improve with every update as the Jolla matures).
>
> And if the chosen API works from a technical point of view, then that does
> not mean that harbour will permit it ... although this too should improve
> with time.
>
> On the whole I have found the Qt documentation to be very good. Where things
> get a bit shaky is using esoteric things like gaining device resource
> permissions (e.g permission to use the LED, or to access the phones
> contacts). For this sort of thing I often have to resort to the source code
> (which at work we call the ultimate documentation .8-) )
>
> mfg
>
> Chris
>
> Zitat von "David Greaves" :
>
>
>> On 03/02/14 15:29, Putze Sven wrote:
>>>
>>> Hi there,
>>>
>>> during Fosdem I spoke to some people about this, even to Carsten Munk
>>> from
>>> Jolla itself (not in the depth and detail of this mail, I must admit) and
>>> he
>>> suggested to write this in the mailing list, so those of Jolla who should
>>> be
>>> concerned have a chance to answer this question and I really would like
>>> to
>>> hear some official statements here.
>>
>>
>> Did you manage to get to the round-table event? - we spent a fair bit of
>> time
>> talking about APIs there; we also openly discussed the issues we face.
>>
>> I know that the community people there wanted to continue the discussion.
>>
>>> What does a developer need to write quality apps? An API and a
>>> documentation
>>> of such.
>>>
>>> So far there is a quite limited API available and therefore we don't see
>>> too
>>> many apps out there. How will you write a sophisticated app, if the API
>>> is
>>> not available or it is not allowed to use or is only known to those with
>>> Maemo/Meego history?
>>
>>
>> A quick response: we support the Qt API and rather than developing our own
>> proprietary one we're working hard to support the open one as it grows.
>>
>> The Qt documentation is extensive and superb :)
>> Using it in Sailfish Silica apps is less well documented but is improving
>> (and
>> honestly is mainly a tutorial issue for new developers - not an API docs
>> issue).
>>
>> Yes there are some APIs in the mobile space that are not part of the Qt
>> release
>> yet - Qt 5.2 will introduce more.
>>
>> David
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>
>
>
> ___
> SailfishOS.org Devel mailing list



-- 
Luciano Montanaro

Anyone who is capable of getting themselves made President should on
no account be allowed to do the job. -- Douglas Adams
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] When does Jolla give us an API?

[christopher . lamb]

Hi all

my experience is that are a vast amount of apis out there: There is  
all the Qt stuff, the Qt add-ons, Nemo packages, and lower-level stuff  
like telepathy and GST. The problem is not the lack of APIs, but the  
choice of APIs. Which is the best one to use?.


Then if you hit on a likely API, and find some good examples on the  
interweb, then it is not sure that that API will fully work on the  
Jolla (although this is likely to improve with every update as the  
Jolla matures).


And if the chosen API works from a technical point of view, then that  
does not mean that harbour will permit it ... although this too should  
improve with time.


On the whole I have found the Qt documentation to be very good. Where  
things get a bit shaky is using esoteric things like gaining device  
resource permissions (e.g permission to use the LED, or to access the  
phones contacts). For this sort of thing I often have to resort to the  
source code (which at work we call the ultimate documentation .8-) )


mfg

Chris

Zitat von "David Greaves" :


On 03/02/14 15:29, Putze Sven wrote:

Hi there,

during Fosdem I spoke to some people about this, even to Carsten Munk from
Jolla itself (not in the depth and detail of this mail, I must admit) and he
suggested to write this in the mailing list, so those of Jolla who should be
concerned have a chance to answer this question and I really would like to
hear some official statements here.


Did you manage to get to the round-table event? - we spent a fair bit of time
talking about APIs there; we also openly discussed the issues we face.

I know that the community people there wanted to continue the discussion.


What does a developer need to write quality apps? An API and a documentation
of such.

So far there is a quite limited API available and therefore we don't see too
many apps out there. How will you write a sophisticated app, if the API is
not available or it is not allowed to use or is only known to those with
Maemo/Meego history?


A quick response: we support the Qt API and rather than developing our own
proprietary one we're working hard to support the open one as it grows.

The Qt documentation is extensive and superb :)
Using it in Sailfish Silica apps is less well documented but is  
improving (and
honestly is mainly a tutorial issue for new developers - not an API  
docs issue).


Yes there are some APIs in the mobile space that are not part of the  
Qt release

yet - Qt 5.2 will introduce more.

David

___
SailfishOS.org Devel mailing list





___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] When does Jolla give us an API?

[David Greaves]

On 03/02/14 15:29, Putze Sven wrote:
> Hi there,
> 
> during Fosdem I spoke to some people about this, even to Carsten Munk from
> Jolla itself (not in the depth and detail of this mail, I must admit) and he
> suggested to write this in the mailing list, so those of Jolla who should be
> concerned have a chance to answer this question and I really would like to
> hear some official statements here.

Did you manage to get to the round-table event? - we spent a fair bit of time
talking about APIs there; we also openly discussed the issues we face.

I know that the community people there wanted to continue the discussion.

> What does a developer need to write quality apps? An API and a documentation
> of such.
> 
> So far there is a quite limited API available and therefore we don't see too
> many apps out there. How will you write a sophisticated app, if the API is
> not available or it is not allowed to use or is only known to those with
> Maemo/Meego history?

A quick response: we support the Qt API and rather than developing our own
proprietary one we're working hard to support the open one as it grows.

The Qt documentation is extensive and superb :)
Using it in Sailfish Silica apps is less well documented but is improving (and
honestly is mainly a tutorial issue for new developers - not an API docs issue).

Yes there are some APIs in the mobile space that are not part of the Qt release
yet - Qt 5.2 will introduce more.

David

___
SailfishOS.org Devel mailing list

[SailfishDevel] When does Jolla give us an API?

[Putze Sven]

Hi there,

during Fosdem I spoke to some people about this, even to Carsten Munk from 
Jolla itself (not in the depth and detail of this mail, I must admit) and he 
suggested to write this in the mailing list, so those of Jolla who should be 
concerned have a chance to answer this question and I really would like to hear 
some official statements here.

Let's just assume the business model of Jolla is selling phones and/or 
operating systems (that is not meant as a joke neither as rant, I simply don't 
know their business model and they don't need to tell me, to make that clear  - 
referring to 
http://stezz.blogspot.de/2013/10/jolla-community-and-innovation.html here). But 
for the sake of convenience I further presume they want to sell phones. Doesn't 
seem too absurd to me.

Jolla must sell phones to pay their bills in the end. More sales = easier life 
(I am simplifying here).

What brings more sales?
A phone that is somehow attractive to the user. So far Jolla lived from the 
geek factor and there is nothing wrong about that but geeks alone are IMHO not 
enough to pay future bills.

What may be attractive to Mr. and Mrs. Average?
A phone that has a somehow *sexy* image? Maybe.
A phone that comes together with an attractive eco system (and I chose the 
words eco system here with thought)?
Yes!
What makes an eco system attractive?
Many quality  *native* apps. *Native* is the keyword here, because many and 
sometimes quality apps can be found on any other platform ou there. Only 
*native* apps come with the user interface that distinguish a Jolla phone from 
other phones (from the user perspective).

What does a developer need to write quality apps?
An API and a documentation of such.

So far there is a quite limited API available and therefore we don't see too 
many apps out there. How will you write a sophisticated app, if the API is not 
available or it is not allowed to use or is only known to those with 
Maemo/Meego history?

Maybe there are not so many developers interested in SailfishOS?
Fosdem clearly showed a lot of interest!

What will draw the attention of a developer to this eco system if not a way to 
make money and/or easy development?
Making money out of the harbour store is not possible (yet), so it could only 
be the latter (ignoring the geek factor here).

So please, please, give us APIs and documentation. Does the API change? So 
what? Life is change and a changing API is a zillion times better to have than 
none at all.

Yes, there is some level of frustration in these words here, but I hope they 
don't come across as a rant. They are meant as constructive criticism and maybe 
as a a broad hint 8)

BR.
Sven


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Carsten Munk FOSSDEM talk

[winfried . dobbe]

I recorded it. However there was a problem with the recording laptops
during Carsten's talk, so it has been recorded in-camera instead and needs
manual editing. (Which has the advantage that the presentation will be
available in a higher resolution than the 720x576 size of the normal
Fosdem recordings).

I hope I can finish the edit this week. Will send an email on this mailing
list when it is online.

regards,
Winfried

> I would expect it to show up here:
>
> http://video.fosdem.org/2014/
>
> once they edited and transcoded everything (if it was recorded ofc)
>
>
>
> On Fri, Jan 31, 2014 at 12:23 AM, Rigoberto Calleja <
> rigober...@alumni.cmu.edu> wrote:
>
>> Hi,
>>
>> Is Carsten's Munk talk at FOSSDEM going to be streamed or recorded?
>>
>> Thanks!
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>
>
>
> --
> Silviu VULCAN
> www.silviuvulcan.ro
>
> Animals are such agreeable friends, they ask no questions, they pass no
> criticism.
> ___
> SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] dbus-sessionbus connection fails

[Kimmo Lindholm]

I need to run my service as root, and my dirty fix to get into sessionbus was 
just to add following into my .service file under [Service]

Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/10/dbus/user_bus_socket

I'm pretty sure that this breaks or violates something, but it seem to work...

-kimmo

From: devel-boun...@lists.sailfishos.org 
[mailto:devel-boun...@lists.sailfishos.org] On Behalf Of Andrey Kozhevnikov
Sent: 3. helmikuuta 2014 12:16
To: devel@lists.sailfishos.org
Subject: Re: [SailfishDevel] dbus-sessionbus connection fails

its not Requires directive, its After
On 03.02.2014 16:11, Luca Donaggio wrote:
Hi Andrey,
yes, I tried with a:
Requires=dbus .service
but I did so many changes to my .service file trying to make it work that I 
can't remember exactly when I did that!
I'll re-start with a clean one and see if it works.

On Mon, Feb 3, 2014 at 11:05 AM, Andrey Kozhevnikov 
mailto:coderusin...@gmail.com>> wrote:
did you added depends for your autostart rule on some system service? otherwise 
it wont start :)

On 03.02.2014 16:01, Luca Donaggio wrote:
I'm fighting with the same issue: starting your dbus-using daemon with 
"systemctl-user start" does work (ie, you'll be able to connect to session 
bus), but autostarting with "systemctl-user enable" doesn't work, while making 
it a system daemon (plain "systemctl" command) works the other way around: it 
doesn't acquire the session bus (even when starting as user "nemo"), but it 
autostarts as expected!

On Sun, Feb 2, 2014 at 9:20 PM, Dmitry 
mailto:energyc...@gmail.com>> wrote:
Hi

You should run your daemon form user systemd unit.
https://wiki.archlinux.org/index.php/Systemd/User

On 1 February 2014 21:53, Kimmo Lindholm 
mailto:kimmo.lindh...@eke.fi>> wrote:
Hi,

I'm using QtDBus in my daemon (systemd service), and I can register my own 
service on systemBus, and also can connect to systembus signals.
When starting executable from command line it runs ok and connects also to the 
sessionbus signals successfully.
but when it is started via systemctl start I can't connect to sessionbus 
signals.

It throws following error:  "Using X11 for dbus-daemon autolaunch was disabled 
at compile time, set your DBUS_SESSION_BUS_ADDRESS instead"

this is printed from code below:

if (!QDBusConnection::sessionBus().isConnected())
{
writeToLog(qPrintable(QDBusConnection::sessionBus().lastError().message()));
exit(EXIT_FAILURE);
}

I figured out that DBUS_SESSION_BUS_ADDRESS  is an environment variable which 
obviously is not visible in this context.

is there a way to pass this to the systemd service??

regards,
Kimmo


___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list



--
Luca Donaggio



___

SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list



--
Luca Donaggio




___

SailfishOS.org Devel mailing list

___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] dbus-sessionbus connection fails

[Luca Donaggio]

Thanks Andrey, I'll try that!


On Mon, Feb 3, 2014 at 11:15 AM, Andrey Kozhevnikov
wrote:

>  its not Requires directive, its After
>
>
> On 03.02.2014 16:11, Luca Donaggio wrote:
>
>   Hi Andrey,
>
>  yes, I tried with a:
>
>  Requires=dbus .service
>
>  but I did so many changes to my .service file trying to make it work that
> I can't remember exactly when I did that!
>  I'll re-start with a clean one and see if it works.
>
>
>
> On Mon, Feb 3, 2014 at 11:05 AM, Andrey Kozhevnikov <
> coderusin...@gmail.com> wrote:
>
>>  did you added depends for your autostart rule on some system service?
>> otherwise it wont start :)
>>
>>
>> On 03.02.2014 16:01, Luca Donaggio wrote:
>>
>> I'm fighting with the same issue: starting your dbus-using daemon with
>> "systemctl-user start" does work (ie, you'll be able to connect to session
>> bus), but autostarting with "systemctl-user enable" doesn't work, while
>> making it a system daemon (plain "systemctl" command) works the other way
>> around: it doesn't acquire the session bus (even when starting as user
>> "nemo"), but it autostarts as expected!
>>
>>
>> On Sun, Feb 2, 2014 at 9:20 PM, Dmitry  wrote:
>>
>>> Hi
>>>
>>>  You should run your daemon form user systemd unit.
>>> https://wiki.archlinux.org/index.php/Systemd/User
>>>
>>>
>>>  On 1 February 2014 21:53, Kimmo Lindholm  wrote:
>>>
   Hi,

 I’m using QtDBus in my daemon (systemd service), and I can register my
 own service on systemBus, and also can connect to systembus signals.
 When starting executable from command line it runs ok and connects also
 to the sessionbus signals successfully.
 but when it is started via systemctl start I can’t connect to
 sessionbus signals.

 It throws following error:  “Using X11 for dbus-daemon autolaunch was
 disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead”

 this is printed from code below:

  if (!QDBusConnection::sessionBus().isConnected())
  {
 writeToLog(qPrintable(QDBusConnection
 ::sessionBus().lastError().message()));
 exit(EXIT_FAILURE);
  }

 I figured out that DBUS_SESSION_BUS_ADDRESS  is an environment
 variable which obviously is not visible in this context.

 is there a way to pass this to the systemd service??

 regards,
 Kimmo


  ___
 SailfishOS.org Devel mailing list

>>>
>>>
>>> ___
>>> SailfishOS.org Devel mailing list
>>>
>>
>>
>>
>> --
>> Luca Donaggio
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>
>
>
> --
> Luca Donaggio
>
>
> ___
> SailfishOS.org Devel mailing list
>
>
>
> ___
> SailfishOS.org Devel mailing list
>



-- 
Luca Donaggio
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] dbus-sessionbus connection fails

[Andrey Kozhevnikov]

its not Requires directive, its After

On 03.02.2014 16:11, Luca Donaggio wrote:

Hi Andrey,

yes, I tried with a:

Requires=dbus .service

but I did so many changes to my .service file trying to make it work 
that I can't remember exactly when I did that!

I'll re-start with a clean one and see if it works.



On Mon, Feb 3, 2014 at 11:05 AM, Andrey Kozhevnikov 
mailto:coderusin...@gmail.com>> wrote:


did you added depends for your autostart rule on some system
service? otherwise it wont start :)


On 03.02.2014 16:01, Luca Donaggio wrote:

I'm fighting with the same issue: starting your dbus-using daemon
with "systemctl-user start" does work (ie, you'll be able to
connect to session bus), but autostarting with "systemctl-user
enable" doesn't work, while making it a system daemon (plain
"systemctl" command) works the other way around: it doesn't
acquire the session bus (even when starting as user "nemo"), but
it autostarts as expected!


On Sun, Feb 2, 2014 at 9:20 PM, Dmitry mailto:energyc...@gmail.com>> wrote:

Hi

You should run your daemon form user systemd unit.
https://wiki.archlinux.org/index.php/Systemd/User


On 1 February 2014 21:53, Kimmo Lindholm
mailto:kimmo.lindh...@eke.fi>> wrote:

Hi,
I'm using QtDBus in my daemon (systemd service), and I
can register my own service on systemBus, and also can
connect to systembus signals.
When starting executable from command line it runs ok and
connects also to the sessionbus signals successfully.
but when it is started via systemctl start I can't
connect to sessionbus signals.
It throws following error:  "Using X11 for dbus-daemon
autolaunch was disabled at compile time, set your
DBUS_SESSION_BUS_ADDRESS instead"
this is printed from code below:
if(!QDBusConnection::sessionBus().isConnected())
{

writeToLog(qPrintable(QDBusConnection::sessionBus().lastError().message()));
exit(EXIT_FAILURE);
}
I figured out that DBUS_SESSION_BUS_ADDRESS is an
environment variable which obviously is not visible in
this context.
is there a way to pass this to the systemd service??
regards,
Kimmo

___
SailfishOS.org Devel mailing list



___
SailfishOS.org Devel mailing list




-- 
Luca Donaggio



___
SailfishOS.org Devel mailing list



___
SailfishOS.org Devel mailing list




--
Luca Donaggio


___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] dbus-sessionbus connection fails

[Luca Donaggio]

Hi Andrey,

yes, I tried with a:

Requires=dbus .service

but I did so many changes to my .service file trying to make it work that I
can't remember exactly when I did that!
I'll re-start with a clean one and see if it works.



On Mon, Feb 3, 2014 at 11:05 AM, Andrey Kozhevnikov
wrote:

>  did you added depends for your autostart rule on some system service?
> otherwise it wont start :)
>
>
> On 03.02.2014 16:01, Luca Donaggio wrote:
>
> I'm fighting with the same issue: starting your dbus-using daemon with
> "systemctl-user start" does work (ie, you'll be able to connect to session
> bus), but autostarting with "systemctl-user enable" doesn't work, while
> making it a system daemon (plain "systemctl" command) works the other way
> around: it doesn't acquire the session bus (even when starting as user
> "nemo"), but it autostarts as expected!
>
>
> On Sun, Feb 2, 2014 at 9:20 PM, Dmitry  wrote:
>
>> Hi
>>
>>  You should run your daemon form user systemd unit.
>> https://wiki.archlinux.org/index.php/Systemd/User
>>
>>
>>  On 1 February 2014 21:53, Kimmo Lindholm  wrote:
>>
>>>   Hi,
>>>
>>> I’m using QtDBus in my daemon (systemd service), and I can register my
>>> own service on systemBus, and also can connect to systembus signals.
>>> When starting executable from command line it runs ok and connects also
>>> to the sessionbus signals successfully.
>>> but when it is started via systemctl start I can’t connect to sessionbus
>>> signals.
>>>
>>> It throws following error:  “Using X11 for dbus-daemon autolaunch was
>>> disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead”
>>>
>>> this is printed from code below:
>>>
>>>  if (!QDBusConnection::sessionBus().isConnected())
>>>  {
>>> writeToLog(qPrintable(QDBusConnection
>>> ::sessionBus().lastError().message()));
>>> exit(EXIT_FAILURE);
>>>  }
>>>
>>> I figured out that DBUS_SESSION_BUS_ADDRESS  is an environment variable
>>> which obviously is not visible in this context.
>>>
>>> is there a way to pass this to the systemd service??
>>>
>>> regards,
>>> Kimmo
>>>
>>>
>>>  ___
>>> SailfishOS.org Devel mailing list
>>>
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>
>
>
> --
> Luca Donaggio
>
>
> ___
> SailfishOS.org Devel mailing list
>
>
>
> ___
> SailfishOS.org Devel mailing list
>



-- 
Luca Donaggio
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] dbus-sessionbus connection fails

[Andrey Kozhevnikov]

did you added depends for your autostart rule on some system service? 
otherwise it wont start :)


On 03.02.2014 16:01, Luca Donaggio wrote:
I'm fighting with the same issue: starting your dbus-using daemon with 
"systemctl-user start" does work (ie, you'll be able to connect to 
session bus), but autostarting with "systemctl-user enable" doesn't 
work, while making it a system daemon (plain "systemctl" command) 
works the other way around: it doesn't acquire the session bus (even 
when starting as user "nemo"), but it autostarts as expected!



On Sun, Feb 2, 2014 at 9:20 PM, Dmitry > wrote:


Hi

You should run your daemon form user systemd unit.
https://wiki.archlinux.org/index.php/Systemd/User


On 1 February 2014 21:53, Kimmo Lindholm mailto:kimmo.lindh...@eke.fi>> wrote:

Hi,
I'm using QtDBus in my daemon (systemd service), and I can
register my own service on systemBus, and also can connect to
systembus signals.
When starting executable from command line it runs ok and
connects also to the sessionbus signals successfully.
but when it is started via systemctl start I can't connect to
sessionbus signals.
It throws following error:  "Using X11 for dbus-daemon
autolaunch was disabled at compile time, set your
DBUS_SESSION_BUS_ADDRESS instead"
this is printed from code below:
if(!QDBusConnection::sessionBus().isConnected())
{

writeToLog(qPrintable(QDBusConnection::sessionBus().lastError().message()));
exit(EXIT_FAILURE);
}
I figured out that DBUS_SESSION_BUS_ADDRESS is an environment
variable which obviously is not visible in this context.
is there a way to pass this to the systemd service??
regards,
Kimmo

___
SailfishOS.org Devel mailing list



___
SailfishOS.org Devel mailing list




--
Luca Donaggio


___
SailfishOS.org Devel mailing list


___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] dbus-sessionbus connection fails

[Luca Donaggio]

I'm fighting with the same issue: starting your dbus-using daemon with
"systemctl-user start" does work (ie, you'll be able to connect to session
bus), but autostarting with "systemctl-user enable" doesn't work, while
making it a system daemon (plain "systemctl" command) works the other way
around: it doesn't acquire the session bus (even when starting as user
"nemo"), but it autostarts as expected!


On Sun, Feb 2, 2014 at 9:20 PM, Dmitry  wrote:

> Hi
>
> You should run your daemon form user systemd unit.
> https://wiki.archlinux.org/index.php/Systemd/User
>
>
> On 1 February 2014 21:53, Kimmo Lindholm  wrote:
>
>>  Hi,
>>
>> I’m using QtDBus in my daemon (systemd service), and I can register my
>> own service on systemBus, and also can connect to systembus signals.
>> When starting executable from command line it runs ok and connects also
>> to the sessionbus signals successfully.
>> but when it is started via systemctl start I can’t connect to sessionbus
>> signals.
>>
>> It throws following error:  “Using X11 for dbus-daemon autolaunch was
>> disabled at compile time, set your DBUS_SESSION_BUS_ADDRESS instead”
>>
>> this is printed from code below:
>>
>>  if (!QDBusConnection::sessionBus().isConnected())
>>  {
>> writeToLog(qPrintable(QDBusConnection
>> ::sessionBus().lastError().message()));
>> exit(EXIT_FAILURE);
>>  }
>>
>> I figured out that DBUS_SESSION_BUS_ADDRESS  is an environment variable
>> which obviously is not visible in this context.
>>
>> is there a way to pass this to the systemd service??
>>
>> regards,
>> Kimmo
>>
>>
>> ___
>> SailfishOS.org Devel mailing list
>>
>
>
> ___
> SailfishOS.org Devel mailing list
>



-- 
Luca Donaggio
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] How to access the viewfinder of the QCamera?

[Andrew den Exter]

> After some digging in the gstreamer debug log it seems that the camera source
> is just supporting the data format video/x-android-buffer and there is no
> equivalent QVideoFrame::PixelFormat for this. Is there really no possibility
> to access the viewfinder in Qt? Then how is the camera app doing that?

The camera app uses it's own scene graph node which is based on a Gstreamer 
sink element (droideglsink) implementing the NemoGstVideoTexture interface 
defined in https://github.com/nemomobile/nemo-gst-interfaces.

We're working on a solution which will allow QtMultimedia's VideoOutput item to 
use that node instead of it's own built in nodes, but in the meantime have been 
accessing it through the GStreamerVideoOutput type which is defined in the 
'Sailfish.Media 1.0' import.


Andrew.
___
SailfishOS.org Devel mailing list

Re: [SailfishDevel] Preventing deep sleep for a few seconds?

[Thomas Perl]

On 01 Feb 2014, at 21:32, Ove Kåven  wrote:
> If a synchronization starts with the screen off, there's a chance that the 
> phone enters "deep suspend" during the synchronization. If so, the other side 
> might time out and the sync will fail.
> 
> So I want prevent the CPU from suspending before the synchronization is 
> complete, which might take a few seconds (and there might not be network 
> activity all the time while it's running). I've read that to get periodic 
> wakeups, you could use libiphb or maybe timed, but what's the recommended way 
> to temporarily prevent suspending completely for a few seconds?

You can talk to MCE via the system D-Bus, this is quite low-level, but works 
already:

https://github.com/nemomobile/mce-dev/blob/master/include/mce/dbus-names.h#L329

To quote the documentation:

 * The idea is: if some process needs to do non-interactive
 * background processing, it can prevent the system from
 * entering late suspend by
 *
 * 1) get timer period via #MCE_CPU_KEEPALIVE_PERIOD_REQ call
 *
 * 2) call #MCE_CPU_KEEPALIVE_START_REQ
 *
 * 3) repeat #MCE_CPU_KEEPALIVE_START_REQ calls in interval
 *that is shorter than the maximum obtained at (1)
 *
 * 4) call #MCE_CPU_KEEPALIVE_STOP_REQ when finished
 *
 * MCE keeps track of active clients and blocks late suspend
 * until all clients have called #MCE_CPU_KEEPALIVE_STOP_REQ,
 * lost D-Bus connection (exit, crash, ...) or all timeouts
 * have been missed.

There might be a higher-level API for this in the future (Qt-flavored C++ and 
QML), for a preview, see:
https://github.com/nemomobile/nemo-keepalive

HTH :)
Thomas
___
SailfishOS.org Devel mailing list