From martin.kampas at jolla.com Mon Oct 10 07:32:30 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Mon, 10 Oct 2016 05:32:30 +0000 Subject: [Automotive] QmlLive: What is the official naming? In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F5E419@ORD2MBX01B.mex05.mlsrvr.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F5E419@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F72D6A@ORD2MBX01B.mex05.mlsrvr.com> BUMP -------------- next part -------------- An HTML attachment was scrubbed... URL: From alistair.adams at qt.io Mon Oct 10 22:52:40 2016 From: alistair.adams at qt.io (Alistair Adams) Date: Mon, 10 Oct 2016 20:52:40 +0000 Subject: [Automotive] QmlLive: What is the official naming? In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F72D6A@ORD2MBX01B.mex05.mlsrvr.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F5E419@ORD2MBX01B.mex05.mlsrvr.com> <597ECB6BFD23CC488EED8B6CD7566AD232F72D6A@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: QmlLive From: Automotive [mailto:automotive-bounces+alistair.adams=qt.io at qt-project.org] On Behalf Of Martin Kampas Sent: Sunday, October 09, 2016 10:33 PM To: automotive ?[automotive at qt-project.org]? Cc: Juergen Bocklage-Ryannel Subject: Re: [Automotive] QmlLive: What is the official naming? BUMP -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kampas at jolla.com Tue Oct 11 10:28:29 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Tue, 11 Oct 2016 08:28:29 +0000 Subject: [Automotive] QmlLive: How to build documentation? Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F7519D@ORD2MBX01B.mex05.mlsrvr.com> Hi, Could someone give me a hint how to build docs after https://codereview.qt-project.org/#/c/170919/ ? Simple make docs fails now as it invokes qdoc with "-outputdir /usr/doc/qmllive". I haven't found an obvious way how to override this. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kampas at jolla.com Tue Oct 11 10:58:29 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Tue, 11 Oct 2016 08:58:29 +0000 Subject: [Automotive] QmlLive: How to build documentation? In-Reply-To: References: <597ECB6BFD23CC488EED8B6CD7566AD232F7519D@ORD2MBX01B.mex05.mlsrvr.com>, Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F7534A@ORD2MBX01B.mex05.mlsrvr.com> Hi Topi, It helped, thanks. Docs updated https://codereview.qt-project.org/#/c/173494/ Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Topi.Reinio at qt.io Tue Oct 11 10:43:58 2016 From: Topi.Reinio at qt.io (=?utf-8?B?VG9waSBSZWluacO2?=) Date: Tue, 11 Oct 2016 08:43:58 +0000 Subject: [Automotive] QmlLive: How to build documentation? In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F7519D@ORD2MBX01B.mex05.mlsrvr.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F7519D@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: Hi Martin, Try CONFIG += force_independent In doc/doc.pri. Not sure if we should actually commit this change ? it might be OK to have there if it doesn?t mess up the packaging of docs. \topi From: Martin Kampas [mailto:martin.kampas at jolla.com] Sent: 11. lokakuuta 2016 10:28 To: automotive ?[automotive at qt-project.org]?; Topi Reini? Subject: QmlLive: How to build documentation? Hi, Could someone give me a hint how to build docs after https://codereview.qt-project.org/#/c/170919/ ? Simple make docs fails now as it invokes qdoc with "-outputdir /usr/doc/qmllive". I haven't found an obvious way how to override this. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kampas at jolla.com Tue Oct 11 11:55:39 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Tue, 11 Oct 2016 09:55:39 +0000 Subject: [Automotive] QmlLive: Release management Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F75618@ORD2MBX01B.mex05.mlsrvr.com> Hi, Would it be possible to tag QmlLive now? What would be the version number? Is QmlLive release cycle meant to be bound to Qt release cycle (as the '5.7' branch name says) or independent (in qmllive.pri we have VERSION=0.1.0 now)? Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen.bocklage-ryannel at pelagicore.com Tue Oct 11 13:01:14 2016 From: juergen.bocklage-ryannel at pelagicore.com (Juergen Ryannel) Date: Tue, 11 Oct 2016 13:01:14 +0200 Subject: [Automotive] QmlLive: What is the official naming? In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F5E419@ORD2MBX01B.mex05.mlsrvr.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F5E419@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: The whole suite is called QmlLive for live coding QML user interfaces. It contains a bench (aka workbench, aka QmlLive Bench) which acts as the central user interface. The runtime is what you use classically on an embedded system to connect with a remote bench. In this sense a runtime is a headless process to be controlled by a bench. qmllive, qml live are not correct. Qt QmlLive is also correct as QmlLive is now part of Qt (Automotive Suite) / jryannel > On 26.09.2016, at 12:11, Martin Kampas wrote: > > Hi, > > What is the official way to reffer to QmlLive (and the bench and runtime in particular)? > > Currently the docs in source tree uses the mix of following: > > $ grep -i '$\(qt\s*$\?\' -r -o -h --binary-files=without-match doc/ --include '*.qdoc' |sort |uniq -c |sort -n -r > 34 QmlLive > 14 runtime > 11 qmllive > 5 workbench > 3 Workbench > 3 QML Live Runtime > 3 QmlLive Runtime > 3 bench > 2 Runtime > 2 QML Live Bench > 2 QmlLive Bench > 2 QML Live > 1 Qt QML Live > 1 QmlLIve > 1 qml live > > The page https://doc.qt.io/QtAutomotiveSuite/qtas-overview.html uses "QmlLive". > > BR, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From juergen.bocklage-ryannel at pelagicore.com Tue Oct 11 13:04:11 2016 From: juergen.bocklage-ryannel at pelagicore.com (Juergen Ryannel) Date: Tue, 11 Oct 2016 13:04:11 +0200 Subject: [Automotive] QmlLive: Release management In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F75618@ORD2MBX01B.mex05.mlsrvr.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F75618@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: <2E4636A1-1A5B-42A4-A174-1AABF0D0002C@pelagicore.com> > On 11.10.2016, at 11:55, Martin Kampas wrote: > > Hi, > > Would it be possible to tag QmlLive now? > > What would be the version number? Is QmlLive release cycle meant to be bound to Qt release cycle (as the '5.7' branch name says) or independent (in qmllive.pri we have VERSION=0.1.0 now)? QmlLive is release with QtAutomotive Suite which is tested with a particular Qt release (hence 5.7). We need to switch to 5.8 branch now (as we target QtAuto 1.1). At least this is my understanding From my taste I really like to bump the version to 1.0 and got for a 1.1 version for 5.8/5.9. / jryannel > > Regards, > Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kampas at jolla.com Tue Oct 11 13:55:43 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Tue, 11 Oct 2016 11:55:43 +0000 Subject: [Automotive] QmlLive: Release management In-Reply-To: <2E4636A1-1A5B-42A4-A174-1AABF0D0002C@pelagicore.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F75618@ORD2MBX01B.mex05.mlsrvr.com>, <2E4636A1-1A5B-42A4-A174-1AABF0D0002C@pelagicore.com> Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F75BC9@ORD2MBX01B.mex05.mlsrvr.com> Hi J?rgen, I am happy with any solution provided it gives me a GIT tag to base my packaging on :) But, IIUC, having mix of 1.x tags and 5.x branches looks a bit odd at first glance. Regards, Martin ________________________________ From: Juergen Ryannel [juergen.bocklage-ryannel at pelagicore.com] Sent: Tuesday, October 11, 2016 1:04 PM To: "automotive ?[automotive at qt-project.org]?" Cc: Martin Kampas Subject: Re: QmlLive: Release management On 11.10.2016, at 11:55, Martin Kampas > wrote: Hi, Would it be possible to tag QmlLive now? What would be the version number? Is QmlLive release cycle meant to be bound to Qt release cycle (as the '5.7' branch name says) or independent (in qmllive.pri we have VERSION=0.1.0 now)? QmlLive is release with QtAutomotive Suite which is tested with a particular Qt release (hence 5.7). We need to switch to 5.8 branch now (as we target QtAuto 1.1). At least this is my understanding >From my taste I really like to bump the version to 1.0 and got for a 1.1 version for 5.8/5.9. / jryannel Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From arasbm at gmail.com Tue Oct 11 22:58:47 2016 From: arasbm at gmail.com (Aras Balali Moghaddam) Date: Tue, 11 Oct 2016 13:58:47 -0700 Subject: [Automotive] What is the proper process for building for release with appman In-Reply-To: <32fa557a-6449-c2ef-bb44-3d10c487a35e@pelagicore.com> References:

<32fa557a-6449-c2ef-bb44-3d10c487a35e@pelagicore.com> Message-ID: Hi, Sorry to bring this topic back up again, but after looking through the docs over and over, I still can not build a package that I could install on another machine. I am creating a package from inside my application source folder: `appman-packager create-package myapp.tar.gz .` This creates a compressed file that contains all the folders and files in the current directory and its subdirectories. I think that should be a clue that I am running the apman-packager from the wrong folder, but where should I run it from instead? When I attempt to install the package with app using `appman-controller` I get the following error: ``` :~$ appman-controller install-package myapp.tar.gz Starting installation of package myapp.tar.gz... ERROR: Could not connect to the D-Bus for io.qt.ApplicationManager: (Not connected to D-Bus server) ``` My development environment is 64bit Linux. My goal is to create a package that I could take to another Linux machine and install it (without having to build again on target device). Any help would be much appreciated. Aras On Thu, Sep 15, 2016 at 10:57 AM, Dominik Holland < dominik.holland at pelagicore.com> wrote: > Hi, > > you might want to look at: > > https://doc.qt.io/QtApplicationManager/appman-packager.html > > for packaging the application and at: > > https://doc-snapshots.qt.io/qtapplicationmanager/appman-controller.html > > for installation. Note the snapshots in the url, as this points to the > latest version of the Documentation. > > In general the application can be packaged on any computer, it doesn't > need to match the architecture where appman is running on. Only if you > need to load binaries like a QML plugin or a native application, this > needs to be available in the correct architecture. > > Best > Dominik > > Am 15.09.16 um 18:26 schrieb Aras Balali Moghaddam: > > My target currently is a 64bit computer running Ubuntu 16.04. Is there > > any documentation on how to package and install my app for this target? > > Searching for application installer documentation takes me tothis API > > document > > applicationinstaller.html#details>which > > makes me think I would have to write an installed app, is that right? > > > > Can I package and install my app on target device just using the > > appman-* command line interface or do I need to write a special Qt > > program for installing my app on target? > > > > Thanks for your help! > > Aras > > > > On Thu, Sep 15, 2016 at 4:12 AM, Vlad Stelmahovsky > > > wrote: > > > > yes, you need to package your app with packager and then deliver it > > to target. How to install it on target depends on the target's > specific > > > > br, > > Vlad > > > > On Tue, Sep 13, 2016 at 12:31 AM, Aras Balali Moghaddam > > > wrote: > > > > Hi automotive and appman people, > > > > I am wondering what the proper procedure is for creating a > > release distribution of an app that I am building that uses > > application manager to run. I am confused with the > > documentation. Do I need to use application package > > r? How > > does one package and install the apps that run with appman on > > production devices? > > > > Cheers, > > Aras > > > > _______________________________________________ > > Automotive mailing list > > Automotive at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/automotive > > > > > > > > > > > > -- > > Best regards, > > Vlad > > > > > > > > > > _______________________________________________ > > Automotive mailing list > > Automotive at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/automotive > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlamothe at docboxinc.com Tue Oct 11 23:58:27 2016 From: jlamothe at docboxinc.com (Jereme Lamothe) Date: Tue, 11 Oct 2016 21:58:27 +0000 Subject: [Automotive] native apps & IPC Message-ID: I'm attempting to get IPC working between the application manager and a native app. Per the documentation, I must re-implement the client side. I've written a C++ class to encapsulate the QDBusConnection / QDBusInterface I need and have deployed it as a plugin, allowing me to test the code in a QML app (launched by the application manager). This test worked, and I've confirmed that a dbus message from the QML app is received by the system UI / app manager. However, using this same code in a native app results in a "No such object path" error (sent by the appman process, in response to ). Seeing the documentation note about "remote interfaces are not available immediately after connecting", I've added a 5 second timer between connection and constructing the QDBusInterface, but to no effect. My question is, have I missed a step in re-implementing the client? I'm only creating a single QDBusInterface for my "com.DocBoxInc.Example" (path: "/ExtensionInterface/com_DocBoxInc_Example"), do I also need to connect to the ApplicationInterface & RuntimeInterface(s) for the /ExtensionInterface path to work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.griebl at pelagicore.com Wed Oct 12 13:58:37 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Wed, 12 Oct 2016 13:58:37 +0200 Subject: [Automotive] What is the proper process for building for release with appman In-Reply-To: References:

<32fa557a-6449-c2ef-bb44-3d10c487a35e@pelagicore.com> Message-ID: On 11.10.2016 22:58, Aras Balali Moghaddam wrote: > Hi, > Sorry to bring this topic back up again, but after looking through the > docs over and over, I still can not build a package that I could install > on another machine. I am creating a package from inside my application > source folder: > > `appman-packager create-package myapp.tar.gz .` > > This creates a compressed file that contains all the folders and files > in the current directory and its subdirectories. I think that should be > a clue that I am running the apman-packager from the wrong folder, but > where should I run it from instead? Seems like it's doing exactly what it should do... see create-package at https://doc.qt.io/QtApplicationManager/appman-packager.html > When I attempt to install the package with app using `appman-controller` > I get the following error: > > ``` > :~$ appman-controller install-package myapp.tar.gz > Starting installation of package myapp.tar.gz... > ERROR: Could not connect to the D-Bus for io.qt.ApplicationManager: > (Not connected to D-Bus server) > ``` What it says - the appman-controller cannot find the appman's D-Bus interface. Most likely you started the appman with --dbus none. I'll improve the error message a bit though. cu Robert From arasbm at gmail.com Wed Oct 12 18:51:48 2016 From: arasbm at gmail.com (Aras Balali Moghaddam) Date: Wed, 12 Oct 2016 09:51:48 -0700 Subject: [Automotive] What is the proper process for building for release with appman In-Reply-To: References:

<32fa557a-6449-c2ef-bb44-3d10c487a35e@pelagicore.com>

Message-ID: Hi Robert, I have read that documentation several times now. There is no example in the documentation and it is not clear what appman-packager actually does. Can I create a `.deb` or an `.apk` package with this tool? But most importantly, my question was: *where* should I run appman-packager from? > Most likely you started the appman with --dbus none No I have never used that option before. Like I mentioned in my previous email, the command I executed was in its simple form: `:~$ appman-controller install-package myapp.tar.gz` I know that part of this pain is my lack of experience with the qt development workflow. But to be honest, the documentation is really lacking context. It is very difficult for new people to get started. I am sure that is not your intention. Thanks! Aras On Wed, Oct 12, 2016 at 4:58 AM, Robert Griebl wrote: > On 11.10.2016 22:58, Aras Balali Moghaddam wrote: > >> Hi, >> Sorry to bring this topic back up again, but after looking through the >> docs over and over, I still can not build a package that I could install >> on another machine. I am creating a package from inside my application >> source folder: >> >> `appman-packager create-package myapp.tar.gz .` >> >> This creates a compressed file that contains all the folders and files >> in the current directory and its subdirectories. I think that should be >> a clue that I am running the apman-packager from the wrong folder, but >> where should I run it from instead? >> > > Seems like it's doing exactly what it should do... see create-package at > https://doc.qt.io/QtApplicationManager/appman-packager.html > > > When I attempt to install the package with app using `appman-controller` >> I get the following error: >> >> ``` >> :~$ appman-controller install-package myapp.tar.gz >> Starting installation of package myapp.tar.gz... >> ERROR: Could not connect to the D-Bus for io.qt.ApplicationManager: >> (Not connected to D-Bus server) >> ``` >> > > What it says - the appman-controller cannot find the appman's D-Bus > interface. Most likely you started the appman with --dbus none. > I'll improve the error message a bit though. > > cu > Robert > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlamothe at docboxinc.com Thu Oct 13 20:15:28 2016 From: jlamothe at docboxinc.com (Jereme Lamothe) Date: Thu, 13 Oct 2016 18:15:28 +0000 Subject: [Automotive] native apps & IPC In-Reply-To: References: Message-ID: I've continued investigating, and believe I have identified the cause. Given two apps, one C++ / native and the other a QML file (still native, using the launcher), different code paths are taken in nativeruntime.cpp in the application manager. In NativeRuntime::onDBusPeerConnection, if m_needsLauncher and m_launchWhenReady are true then NativeRuntime::onLauncherFinishedInitialization() is called and all extension interfaces are registered. My native C++ application doesn't require a launcher, therefore those booleans are false, and the extension interfaces are never registered. Is this behavior intentional? The documentation for ApplicationInterface led me to believe it would be possible to re-implement the client side, such that I could continue to use ApplicationIPCInterface in my SystemUI. Modifying NativeRuntime::onDBusPeerConnection() to, in the case of a native C++ app, register all extension interfaces results in successful communication on the peer DBus between my client and the system ui. On Tue, Oct 11, 2016 at 5:58 PM Jereme Lamothe wrote: > I'm attempting to get IPC working between the application manager and a > native app. Per the documentation, I must re-implement the client side. > I've written a C++ class to encapsulate the QDBusConnection / > QDBusInterface I need and have deployed it as a plugin, allowing me to test > the code in a QML app (launched by the application manager). This test > worked, and I've confirmed that a dbus message from the QML app is received > by the system UI / app manager. However, using this same code in a native > app results in a "No such object path" error (sent by the appman process, > in response to ). Seeing the documentation note about "remote interfaces > are not available immediately after connecting", I've added a 5 second > timer between connection and constructing the QDBusInterface, but to no > effect. > > My question is, have I missed a step in re-implementing the client? I'm > only creating a single QDBusInterface for my "com.DocBoxInc.Example" (path: > "/ExtensionInterface/com_DocBoxInc_Example"), do I also need to connect to > the ApplicationInterface & RuntimeInterface(s) for the /ExtensionInterface > path to work? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.griebl at pelagicore.com Fri Oct 14 00:08:38 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Fri, 14 Oct 2016 00:08:38 +0200 Subject: [Automotive] native apps & IPC In-Reply-To: References:

Message-ID: Hi Jereme, On 13.10.2016 20:15, Jereme Lamothe wrote: > [...] > Is this behavior intentional? The documentation for ApplicationInterface > led me to believe it would be possible to re-implement the client side, > such that I could continue to use ApplicationIPCInterface in my > SystemUI. Modifying NativeRuntime::onDBusPeerConnection() to, in the > case of a native C++ app, register all extension interfaces results in > successful communication on the peer DBus between my client and the > system ui. That's a plain bug - most likely just a copy&paste oversight when I introduced the onLauncherFinishedInitialization() call to get rid of a pesky race condition. Your fix is most likely correct, but I'd like to do some tests first to avoid that we're re-introducing a race condition. It would be nice if you could a bugreport on http://bugreport.qt.io AUTOSUITE / ApplicationManager, so I cannot forget about it. Thanks, Robert > > On Tue, Oct 11, 2016 at 5:58 PM Jereme Lamothe > wrote: > > I'm attempting to get IPC working between the application manager > and a native app. Per the documentation, I must re-implement the > client side. I've written a C++ class to encapsulate the > QDBusConnection / QDBusInterface I need and have deployed it as a > plugin, allowing me to test the code in a QML app (launched by the > application manager). This test worked, and I've confirmed that a > dbus message from the QML app is received by the system UI / app > manager. However, using this same code in a native app results in a > "No such object path" error (sent by the appman process, in response > to ). Seeing the documentation note about "remote interfaces are not > available immediately after connecting", I've added a 5 second timer > between connection and constructing the QDBusInterface, but to no > effect. > > My question is, have I missed a step in re-implementing the client? > I'm only creating a single QDBusInterface for my > "com.DocBoxInc.Example" (path: > "/ExtensionInterface/com_DocBoxInc_Example"), do I also need to > connect to the ApplicationInterface & RuntimeInterface(s) for the > /ExtensionInterface path to work? > > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > -- Robert Griebl Senior Software Engineer Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From jlamothe at docboxinc.com Fri Oct 14 14:05:04 2016 From: jlamothe at docboxinc.com (Jereme Lamothe) Date: Fri, 14 Oct 2016 12:05:04 +0000 Subject: [Automotive] native apps & IPC In-Reply-To: References:

Message-ID: I've created a bug report and attached my workaround as a patch. https://bugreports.qt.io/browse/AUTOSUITE-24 On Thu, Oct 13, 2016 at 6:08 PM Robert Griebl wrote: > Hi Jereme, > > On 13.10.2016 20:15, Jereme Lamothe wrote: > > [...] > > Is this behavior intentional? The documentation for ApplicationInterface > > led me to believe it would be possible to re-implement the client side, > > such that I could continue to use ApplicationIPCInterface in my > > SystemUI. Modifying NativeRuntime::onDBusPeerConnection() to, in the > > case of a native C++ app, register all extension interfaces results in > > successful communication on the peer DBus between my client and the > > system ui. > > That's a plain bug - most likely just a copy&paste oversight when I > introduced the onLauncherFinishedInitialization() call to get rid of a > pesky race condition. > > Your fix is most likely correct, but I'd like to do some tests first to > avoid that we're re-introducing a race condition. > > It would be nice if you could a bugreport on http://bugreport.qt.io > AUTOSUITE / ApplicationManager, so I cannot forget about it. > > Thanks, > Robert > > > > > > > On Tue, Oct 11, 2016 at 5:58 PM Jereme Lamothe > > wrote: > > > > I'm attempting to get IPC working between the application manager > > and a native app. Per the documentation, I must re-implement the > > client side. I've written a C++ class to encapsulate the > > QDBusConnection / QDBusInterface I need and have deployed it as a > > plugin, allowing me to test the code in a QML app (launched by the > > application manager). This test worked, and I've confirmed that a > > dbus message from the QML app is received by the system UI / app > > manager. However, using this same code in a native app results in a > > "No such object path" error (sent by the appman process, in response > > to ). Seeing the documentation note about "remote interfaces are not > > available immediately after connecting", I've added a 5 second timer > > between connection and constructing the QDBusInterface, but to no > > effect. > > > > My question is, have I missed a step in re-implementing the client? > > I'm only creating a single QDBusInterface for my > > "com.DocBoxInc.Example" (path: > > "/ExtensionInterface/com_DocBoxInc_Example"), do I also need to > > connect to the ApplicationInterface & RuntimeInterface(s) for the > > /ExtensionInterface path to work? > > > > > > > > _______________________________________________ > > Automotive mailing list > > Automotive at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/automotive > > > > > -- > Robert Griebl > Senior Software Engineer > > Pelagicore AG > Balanstr. 55, 81541 Munich, Germany > robert.griebl at pelagicore.com > www.pelagicore.com > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsanche1 at jaguarlandrover.com Fri Oct 14 18:05:40 2016 From: jsanche1 at jaguarlandrover.com (Sanchez, Jack) Date: Fri, 14 Oct 2016 09:05:40 -0700 Subject: [Automotive] appman use case question Message-ID: Hi all, I'm going to begin investigating this now but I thought I'd throw out my questions in parallel. It certainly seems apparent that appman requires root privileges in order to properly run and gain access to input and graphics devices on the system. If this is not the case, I would be interested in hearing anything I may be missing at this point for that. In our system, we require that our HMI applications actually run as a user other than root for security reasons, however, since appman is doing lifecycle management, all the processes will inherit this root environment. So we need to be able to launch our HMI apps through appman from another user session in order to be on the same DBUS session as our system services being communicated with (controlling hardware). Even if we are able to do this - I'm assuming the difference in DBUS sessions from root to the other user will also potentially impede communications between appman and the appman-based HMI processes. Has anyone already handled this issue and/or are there plans in place for the QtAS development teams to add in this type of functionality? Would we need to fork and do this work ourselves in order to break apart this coupling? Basically we just want to use appman as more of a server based compositor as Weston is used, and be able to dynamically attach HMI processes to the appman server. Thanks for any help! Best regards, -- *Jack Sanchez* Lead Qt Engineer *M:* +1 503-608-8282 *E: jsanche1 at jaguarlandrover.com * *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA* *jaguar.com | landrover.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsanche1 at jaguarlandrover.com Fri Oct 14 20:12:03 2016 From: jsanche1 at jaguarlandrover.com (Sanchez, Jack) Date: Fri, 14 Oct 2016 11:12:03 -0700 Subject: [Automotive] QtApplicationManager disable-installer flag Message-ID: Hi all, Another quick question that is merely more of an annoyance than a problem. It seems that you cannot actually use the "-config disable-installer" flag during qmake and build time. The QtApplicationManager project seems that not all cases are handled for this, build steps and error output follows: qmake -config disable-installer make ------error compiler output---------- g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC -DAM_DISABLE_INSTALLER -DAM_USE_LIBBACKTRACE -DAM_MULTI_PROCESS -DAM_VERSION=\"1.0.0\" -DAM_USE_LIBCRYPTO -DAM_BUILD_APPMAN -DQT_WAYLANDCOMPOSITOR_LIB -DQT_COMPOSITOR_WAYLAND_GL -DQT_QUICK_LIB -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB -I. -I../common-lib -I../manager-lib -I../installer-lib -I../notification-lib -I/opt/Qt-5.7.0/include/QtWaylandCompositor/5.7.0 -I/opt/Qt-5.7.0/include/QtWaylandCompositor/5.7.0/QtWaylandCompositor -I/opt/Qt-5.7.0/include -I/opt/Qt-5.7.0/include/QtWaylandCompositor -I/opt/Qt-5.7.0/include/QtQuick/5.7.0 -I/opt/Qt-5.7.0/include/QtQuick/5.7.0/QtQuick -I/opt/Qt-5.7.0/include/QtQuick -I/opt/Qt-5.7.0/include/QtQml/5.7.0 -I/opt/Qt-5.7.0/include/QtQml/5.7.0/QtQml -I/opt/Qt-5.7.0/include/QtQml -I/opt/Qt-5.7.0/include/QtNetwork -I/opt/Qt-5.7.0/include/QtGui/5.7.0 -I/opt/Qt-5.7.0/include/QtGui/5.7.0/QtGui -I/opt/Qt-5.7.0/include/QtCore/5.7.0 -I/opt/Qt-5.7.0/include/QtCore/5.7.0/QtCore -I/opt/Qt-5.7.0/include/QtGui -I/opt/Qt-5.7.0/include/QtDBus -I/opt/Qt-5.7.0/include/QtCore -I. -I/opt/Qt-5.7.0/mkspecs/linux-g++ -o qrc_config.o qrc_config.cpp main.cpp:322:71: error: ?InstallationLocation? was not declared in this scope const QVector &installationLocations) ^ main.cpp:322:91: error: template argument 1 is invalid const QVector &installationLocations) ^ main.cpp: In member function ?virtual void main(int, char**)::DBusDaemonProcess::setupChildProcess()?: main.cpp:525:45: error: ?SIGKILL? was not declared in this scope prctl(PR_SET_PDEATHSIG, SIGKILL); ^ main.cpp: In function ?int main(int, char**)?: main.cpp:614:44: error: ?installationLocations? was not declared in this scope installationLocations); ^ Makefile:2619: recipe for target 'main.o' failed ------end error compiler output---------- An extension to this issue is that it seems the project completely ignores all qmake config flags. The other case we have tried to use is the "-config install-prefix" to point somewhere other than /usr/local, however, this is also ignored by the build system. Thanks again as always!! Best regards, -- *Jack Sanchez* Lead Qt Engineer *M:* +1 503-608-8282 *E: jsanche1 at jaguarlandrover.com * *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA* *jaguar.com | landrover.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.holland at pelagicore.com Fri Oct 14 20:19:25 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Fri, 14 Oct 2016 20:19:25 +0200 Subject: [Automotive] QtApplicationManager disable-installer flag In-Reply-To: References: Message-ID: <47d7e4e3-7d63-55ee-bd5c-9f0f7a00ec75@pelagicore.com> Hi, yes this is a bug. It would be nice if you could add a bugreport on http://bugreport.qt.io AUTOSUITE / ApplicationManager. Please also add the environment you build this on. Dominik Am 14.10.16 um 20:12 schrieb Sanchez, Jack: > Hi all, > > Another quick question that is merely more of an annoyance than a problem. > > It seems that you cannot actually use the "-config disable-installer" > flag during qmake and build time. The QtApplicationManager project seems > that not all cases are handled for this, build steps and error output > follows: > > qmake -config disable-installer > make > > ------error compiler output---------- > g++ -c -pipe -g -std=gnu++11 -Wall -W -D_REENTRANT -fPIC > -DAM_DISABLE_INSTALLER -DAM_USE_LIBBACKTRACE -DAM_MULTI_PROCESS > -DAM_VERSION=\"1.0.0\" -DAM_USE_LIBCRYPTO -DAM_BUILD_APPMAN > -DQT_WAYLANDCOMPOSITOR_LIB -DQT_COMPOSITOR_WAYLAND_GL -DQT_QUICK_LIB > -DQT_QML_LIB -DQT_NETWORK_LIB -DQT_GUI_LIB -DQT_DBUS_LIB -DQT_CORE_LIB > -I. -I../common-lib -I../manager-lib -I../installer-lib > -I../notification-lib -I/opt/Qt-5.7.0/include/QtWaylandCompositor/5.7.0 > -I/opt/Qt-5.7.0/include/QtWaylandCompositor/5.7.0/QtWaylandCompositor > -I/opt/Qt-5.7.0/include -I/opt/Qt-5.7.0/include/QtWaylandCompositor > -I/opt/Qt-5.7.0/include/QtQuick/5.7.0 > -I/opt/Qt-5.7.0/include/QtQuick/5.7.0/QtQuick > -I/opt/Qt-5.7.0/include/QtQuick -I/opt/Qt-5.7.0/include/QtQml/5.7.0 > -I/opt/Qt-5.7.0/include/QtQml/5.7.0/QtQml -I/opt/Qt-5.7.0/include/QtQml > -I/opt/Qt-5.7.0/include/QtNetwork -I/opt/Qt-5.7.0/include/QtGui/5.7.0 > -I/opt/Qt-5.7.0/include/QtGui/5.7.0/QtGui > -I/opt/Qt-5.7.0/include/QtCore/5.7.0 > -I/opt/Qt-5.7.0/include/QtCore/5.7.0/QtCore > -I/opt/Qt-5.7.0/include/QtGui -I/opt/Qt-5.7.0/include/QtDBus > -I/opt/Qt-5.7.0/include/QtCore -I. -I/opt/Qt-5.7.0/mkspecs/linux-g++ -o > qrc_config.o qrc_config.cpp > main.cpp:322:71: error: ?InstallationLocation? was not declared in this > scope > const > QVector &installationLocations) > ^ > main.cpp:322:91: error: template argument 1 is invalid > const > QVector &installationLocations) > > ^ > main.cpp: In member function ?virtual void main(int, > char**)::DBusDaemonProcess::setupChildProcess()?: > main.cpp:525:45: error: ?SIGKILL? was not declared in this scope > prctl(PR_SET_PDEATHSIG, SIGKILL); > ^ > main.cpp: In function ?int main(int, char**)?: > main.cpp:614:44: error: ?installationLocations? was not declared in this > scope > installationLocations); > ^ > Makefile:2619: recipe for target 'main.o' failed > ------end error compiler output---------- > > An extension to this issue is that it seems the project completely > ignores all qmake config flags. The other case we have tried to use is > the "-config install-prefix" to point somewhere other than /usr/local, > however, this is also ignored by the build system. > > Thanks again as always!! > > Best regards, > -- > *Jack Sanchez* > Lead Qt Engineer > > *M:* +1 503-608-8282 > *E: jsanche1 at jaguarlandrover.com * > > *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA* > *jaguar.com | landrover.com * > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > From david.boosalis at gmail.com Tue Oct 18 18:07:23 2016 From: david.boosalis at gmail.com (David Boosalis) Date: Tue, 18 Oct 2016 09:07:23 -0700 Subject: [Automotive] How to go from built sysroot to image Message-ID: Hi All I have built neptune from git with my 30 day eval of Qt-Automotive. The install files went to a sysroot that is part of my Qt Automove SDK : "/home/david/QtE/5.7/Automotive/nitrogen6x/toolchain/sysroots" I would not like to put it into the imx6 image provided to me as part of the Qt Automotive: "/home/david/QtE/5.7/Automotive/nitrogen6x/images/b2qt-automotive-qt5-image-nitrogen6x.img" Then copy to this to sdio card, but not sure the best way to copy my sysroot to the img. Any advise very much appreciated. -David -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremiah.foster at pelagicore.com Wed Oct 19 18:33:58 2016 From: jeremiah.foster at pelagicore.com (Jeremiah Foster) Date: Wed, 19 Oct 2016 09:33:58 -0700 Subject: [Automotive] Call for participation -- FOSDEM 2017 embedded, mobile and automotive devroom Message-ID: Hello, This email is a Call For Participation in the embedded, mobile and automotive devroom FOSDEM 201 ?7? Devroom date: Saturday ?February 4th? and Sunday ?5th? 201 ?7? in Brussels, Belgium CFP deadline: Monday, December ?12? th ?,? 201 ?6? Final speaker confirmation on Friday, December 1 ?6? th 201 ?6? CFP Introduction --------------------------- Embedded software is transforming the world, and FOSS embedded software is leading the way. From automotive to the Internet of Things, launching rockets, messing with your phone or automating your toaster, small devices, embedded systems, and automatons are everywhere Join in and tell the world about your project! NB: This year FOSDEM plans to record all presentations, no exceptions. Please only propose a talk that you're really able and willing to share. Topics Sought ------------------------ The embedded devroom seeks topics related to automotive, mobile, autonomous, and generally small systems. Related areas are of course of interest as ? ? well and our definition of "embedded" is elastic. CFP Schedule And Submission Details ----------------------------------------------------------- Please submit proposals no later than the ?12? th of December. Please use the following URL to submit your talk to FOSDEM 201 ?7? : ??https://penta.fosdem.org/submission/FOSDEM17 and follow the following rules: * If you do not have an account yet ?, please? create one, if you have submitted a talk in one of the previous years ?, please? re-use your old account. * Select as the Track "embedded devroom". * Select as the Event Type "Lecture" * Include a title. (Note that "Subtitle" entry doesn't appear on all conference documents, so make sure "Title" can stand on its own without "Subtitle" present.) * Include an Abstract of about 500 characters and a full description of any length you wish, but in both fields, please be concise, but clear and descriptive. * Indicate whether you seek a 25, or 50 minute slot. * Use the "Links" sub-area to your past work in the field you'd like to share. * Also in the notes field, confirmation your availability to speak on Saturday 30 January or 31 February 2016 in Brussels. * Last but not least, make sure you have up to date contact info. Feel free to send an email to the embedded mailing list should you have any questions with the conference system. Subscribe here: https://lists.fosdem.org/listinfo/embedded-devroom About the devroom organizers -------------------------------------------------- The co-organizers of the FOSDEM 2016 Embedded devroom are (in alphabetical order by surname): - Peter De Schrijver, Kernel engineer at Nvidia - Philippe De Swert, HW adaptation engineer at Nomovok - Jeremiah C. Foster, GENIVI Community Manager - Thomas Petazzoni, CTO Free Electrons - Geert Uytterhoeven, Glider bvba -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.griebl at pelagicore.com Thu Oct 20 14:46:29 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Thu, 20 Oct 2016 14:46:29 +0200 Subject: [Automotive] appman use case question In-Reply-To: References: Message-ID: Hi Jack, Sorry for the late reply. On 14.10.2016 18:05, Sanchez, Jack wrote: > It certainly seems apparent that appman requires root privileges in > order to properly run and gain access to input and graphics devices on > the system. If this is not the case, I would be interested in hearing > anything I may be missing at this point for that. That is certainly not the case. Quite the opposite: you shouldn't run the AM as root, although you need to have it SUID-root if you want to use the installer part (only a small helper process will continue to run with root privileges in this case -- the main process will drop them immediately) Gaining access to devices is done via standard Unix file permissions in /dev. Of course you have to adjust those if you are running non-root. We have done embedded, Yocto based non-root installations in the past without any major problems (the biggest one being to make sure that everyone ends up on the same session bus, but this was basically a fiddling around with systemd units). cu Robert > In our system, we require that our HMI applications actually run as a > user other than root for security reasons, however, since appman is > doing lifecycle management, all the processes will inherit this root > environment. > > So we need to be able to launch our HMI apps through appman from another > user session in order to be on the same DBUS session as our system > services being communicated with (controlling hardware). > > Even if we are able to do this - I'm assuming the difference in DBUS > sessions from root to the other user will also potentially impede > communications between appman and the appman-based HMI processes. > > Has anyone already handled this issue and/or are there plans in place > for the QtAS development teams to add in this type of functionality? > Would we need to fork and do this work ourselves in order to break apart > this coupling? > > Basically we just want to use appman as more of a server based > compositor as Weston is used, and be able to dynamically attach HMI > processes to the appman server. > > Thanks for any help! > > Best regards, > -- > *Jack Sanchez* > Lead Qt Engineer > > *M:* +1 503-608-8282 > *E: jsanche1 at jaguarlandrover.com * > > *Jaguar Land Rover, 1419 NW 14th Ave, Portland, Oregon, 97209, USA* > *jaguar.com | landrover.com * > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > -- Robert Griebl Senior Software Engineer Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From robert.griebl at pelagicore.com Thu Oct 20 14:53:14 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Thu, 20 Oct 2016 14:53:14 +0200 Subject: [Automotive] QtApplicationManager disable-installer flag In-Reply-To: References: Message-ID: Hi Jack, On 14.10.2016 20:12, Sanchez, Jack wrote: > It seems that you cannot actually use the "-config disable-installer" > flag during qmake and build time. The QtApplicationManager project seems > that not all cases are handled for this, build steps and error output > follows: Fixed in the 5.7 branch by 21ae572 > An extension to this issue is that it seems the project completely > ignores all qmake config flags. The other case we have tried to use is > the "-config install-prefix" to point somewhere other than /usr/local, > however, this is also ignored by the build system. -config install-prefix should be removed anyway, since it doesn't make sense anymore with 21ae572 in place (the AM is a real Qt module now and binaries end up in qtbase/bin). Not removing the flag plus its documentation was an oversight - will fix that soon. The rest of the config options should work though (and they do for us). Could you give me another example of what does not work? cu Robert -- Robert Griebl Senior Software Engineer Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From martin.kampas at jolla.com Fri Oct 21 11:04:42 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Fri, 21 Oct 2016 09:04:42 +0000 Subject: [Automotive] QmlLive: Release management In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F75BC9@ORD2MBX01B.mex05.mlsrvr.com> References: <597ECB6BFD23CC488EED8B6CD7566AD232F75618@ORD2MBX01B.mex05.mlsrvr.com>, <2E4636A1-1A5B-42A4-A174-1AABF0D0002C@pelagicore.com>, <597ECB6BFD23CC488EED8B6CD7566AD232F75BC9@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F86B02@ORD2MBX01B.mex05.mlsrvr.com> BUMP From jsanche1 at jaguarlandrover.com Sun Oct 23 02:44:10 2016 From: jsanche1 at jaguarlandrover.com (Sanchez, Jack) Date: Sat, 22 Oct 2016 17:44:10 -0700 Subject: [Automotive] QMLProfiler with appman based system Message-ID: Hello again, I'm trying to get a QMLProfiler session running against my appman based system, however, this does not seem possible. I have built the appman project in debug mode (i.e. including CONFIG+=declarative_debug CONFIG+=qml_debug) and have spent a couple hours attempting to build in QML/JS debugging options in order to be able to launch the system with the profiler through QtCreator. My QtCreator run configuration looks something like this: Executable: appman Command line args: -r -c "/opt/am/config.yaml" -c $AM_CONFIG --fullscreen --verbose Working directory: As well as a few basic environment variables. With this configuration I would like to be able to launch with the profiler attached, although I have also tried to attach externally. Is this use case intended to be supported, or should I look for another way to accomplish this goal? Ideally I'd like to avoid tedious creation of dummyimports (which can somewhat mislead the overall performance metrics) and usage of qmlscene. Thanks as always! -- *Jack Sanchez* Lead Qt Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsanche1 at jaguarlandrover.com Sun Oct 23 03:07:38 2016 From: jsanche1 at jaguarlandrover.com (Sanchez, Jack) Date: Sat, 22 Oct 2016 18:07:38 -0700 Subject: [Automotive] Help debugging multi process mode with appman Message-ID: Hi all, Another subject question for the group. When trying to run the system in multi process mode I get wayland surface failures when starting with ApplicationManager.startApplication(id, document), which is returning true. I am testing this against a simple qml runtime application. -- Runtime output -- [DBG | qt.egl.xlib.debug] Using Opaque Visual ID 33 provided by EGL for config 58 [qxlibeglintegration.cpp:124] [DBG | am.system] Found a quick-launch entry for container "process" and runtime "qml" -> QObject(0x0) QObject(0x0) [applicationmanager.cpp:644] [DBG | am.system] Running command: "/usr/local/bin/appman-launcher-qml" () [ processcontainer.cpp:209] [DBG | am.wayland] waylandSurfaceCreate Surface(0x30bb550) (PID: 4717 ) QMap() [windowmanager.cpp:633] [DBG | default] Using Wayland-EGL [qwaylandeglclientbufferintegration.cpp:62 ] [DBG | am.wayland] waylandSurfaceCreate Surface(0x3095820) (PID: 4717 ) QMap() [windowmanager.cpp:633] [WARN | default] EglClientBufferIntegration: creating texture with no current context [waylandeglclientbufferintegration.cpp:275] [WARN | default] void WaylandEglClientBufferIntegrationPrivate::bindBuffer(wl_resource*):325: eglStreamConsumerGLTextureExternalKHR failed: 0x3002 [ waylandeglclientbufferintegration.cpp:325] [WARN | default] QObject::connect: No such signal org::freedesktop::Notifications::NotificationClosed(uint,uint) in qmlapplicationinterface.cpp:123 [qobject.cpp:2282] [CRIT | default] ERROR: could not connect the org.freedesktop.Notifications interface via D-Bus: [qmlapplicationinterface.cpp:127] [CRIT | default] ERROR: could not connect to the application manager's interface on the peer D-Bus [main.cpp:206] [DBG | am.wayland] waylandSurfaceDestroyed 0x3095838 [windowmanager.cpp:702] [WARN | am.wayland] waylandSurfaceDestroyed: could not find an application window for surface 0x3095838 [windowmanager.cpp:705] -- end output -- On our embedded targets, this causes segfaults the next time you attempt to interact with the surfaces, on my development environments this usually just causing the system to hang indefinitely with the appearance of still responding to input. My guesses to what this may be related to in terms of possible library compatibility issues are: * libGLESv2.so from nvidia-364 (although this is not what is used on the targets) * libwayland-* or * something in Qt5 Gui/Declarative/Core/etc I'm hoping this is just us missing something in the usages of appman's QML types, we have had multi process working many weeks ago on both dev machines and targets, so perhaps one of the APIs changed in either ApplicationManager, WindowManager, or ApplicationManagerWindow? Any help on this one would be immensely appreciated!! Best, -- *Jack Sanchez* Lead Qt Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: