From juergen.bocklage-ryannel at pelagicore.com Thu Sep 1 08:42:44 2016 From: juergen.bocklage-ryannel at pelagicore.com (Juergen Ryannel) Date: Thu, 1 Sep 2016 08:42:44 +0200 Subject: [Automotive] Sandboxing for System Installed Application In-Reply-To: <597ECB6BFD23CC488EED8B6CD7566AD232F54A95@ORD2MBX01B.mex05.mlsrvr.com> References: <820C8AA4-CF58-4A38-990E-5052C26719CB@pelagicore.com> <597ECB6BFD23CC488EED8B6CD7566AD232F54A95@ORD2MBX01B.mex05.mlsrvr.com> Message-ID: <70EF4194-246A-466E-BF8B-94AD041ACC4B@pelagicore.com> Hi, > On 25.08.2016, at 15:59, Martin Kampas wrote: > > Hi J?rgen, > >> This should be only be useful if you create a custom live enabled runtime which is installed on a device (for example a tablet) and is not allowed to write into its installed folder. In this case it need to find a writeable place for it?s data. Correct? >> Or is it more the use case that there is a read-only workspace on a remote device and still we would like to update the user interface? > > It applies also to the case when the standard QmlLive Runtime is used. I updated the documentation, explaining: > > """Not all projects are designed so that they allow working on isolated panels or > screens and it may be necessary to deploy whole project to a target device in > order to execute it. Receiving updates normally requires write access to the > deployed files. Depending on the target platform, the project may be deployed to > a location which is not user writable. In most cases hacking on the file > permissions after deployment can help, but a more convenient method is available > - let the runtime store all updates in a writable workspace overlay. Use the \c > -updates-as-overlay option to enable this feature.?"" Thanks for the update. This makes the use case more clear. I will need to update the qt documentation for this. Maybe you did already. > >> So we could either lookup a temporary folder or ask QStandardPaths for a writeable location. In both cases the implementation makes a choice. >> Personally I would like to see that there is a default strategy to find a writeable workspace location, which is not inside the implementation but can be set onto the livenode in case something is not writeable. > > It uses QDir::tempPath() to find such a location. It can be influenced by setting a platform specific environment variable. The following change set further extends this to also use application and company name in order to get app specific path, much like it is done by QSettings (this needs to be a bit tuned for the case with the standard runtime). > > I considered to allow overriding the location with a dedicated environment variable but I abandoned this idea as too dangerous - the location is subject to "rm -rf" and I do not want to imagine someone misunderstanding and setting it to $HOME or $PROJECTS or whatever valuable location :) > > Every project may have its specific constraints - I would rather let the user control the mechanism used. > > This also serves as a preparation step for adding support to receive updates for compiled-in resources (qrc). > > I am thinking maybe the overlay should be persistent by default? Lets see. If you use a writeable location. Surely the changes are persistent. If you use a read only location then the changes would be currently not persistent and purged on remote runtime exit. From the user perspective when he looks at the QML code of the remote workspace he would see in the read-only case his original source code and would not understand why the code behaves differently. Sure this is the opposite in the writeable workspace use case. After restarting the remote runtime in the read-only workspace use case the user would need to press publish all to sync its workspace again. So it might be just the question to automate this syncing. Either by announcing to the bench: The remote workspace is a read-only workspace, on re-connection please publish all automatically or the remove runtime request the sync automatically on startup and maybe this behavior could be omitted. The other option would be to announce only to the bench that the workspace is read-only and we can add an action to auto-sync on connection to the target. Most flexibility but adds an option, I would prefer a good default behavior. So it seems I?m not in favor of persistent temporary data. And more in finding a transparent good default behavior for applying a sync on re-connect. / jryannel > BR, > Martin From juergen.bocklage-ryannel at pelagicore.com Thu Sep 1 08:47:58 2016 From: juergen.bocklage-ryannel at pelagicore.com (Juergen Ryannel) Date: Thu, 1 Sep 2016 08:47:58 +0200 Subject: [Automotive] Sandboxing for System Installed Application In-Reply-To: <70EF4194-246A-466E-BF8B-94AD041ACC4B@pelagicore.com> References: <820C8AA4-CF58-4A38-990E-5052C26719CB@pelagicore.com> <597ECB6BFD23CC488EED8B6CD7566AD232F54A95@ORD2MBX01B.mex05.mlsrvr.com> <70EF4194-246A-466E-BF8B-94AD041ACC4B@pelagicore.com> Message-ID: <92D4EA6D-4761-4F1A-945E-58AD225AA392@pelagicore.com> Hi, I should have first look at the patch :-) Adding an option to use a temporary overlay or a persistent overlay is surely also an option. So forget about this mail. Cool! / jryannel > On 01.09.2016, at 08:42, Juergen Ryannel wrote: > > Hi, > >> On 25.08.2016, at 15:59, Martin Kampas wrote: >> >> Hi J?rgen, >> >>> This should be only be useful if you create a custom live enabled runtime which is installed on a device (for example a tablet) and is not allowed to write into its installed folder. In this case it need to find a writeable place for it?s data. Correct? >>> Or is it more the use case that there is a read-only workspace on a remote device and still we would like to update the user interface? >> >> It applies also to the case when the standard QmlLive Runtime is used. I updated the documentation, explaining: >> >> """Not all projects are designed so that they allow working on isolated panels or >> screens and it may be necessary to deploy whole project to a target device in >> order to execute it. Receiving updates normally requires write access to the >> deployed files. Depending on the target platform, the project may be deployed to >> a location which is not user writable. In most cases hacking on the file >> permissions after deployment can help, but a more convenient method is available >> - let the runtime store all updates in a writable workspace overlay. Use the \c >> -updates-as-overlay option to enable this feature.?"" > > Thanks for the update. This makes the use case more clear. I will need to update the qt documentation for this. Maybe you did already. > >> >>> So we could either lookup a temporary folder or ask QStandardPaths for a writeable location. In both cases the implementation makes a choice. >>> Personally I would like to see that there is a default strategy to find a writeable workspace location, which is not inside the implementation but can be set onto the livenode in case something is not writeable. >> >> It uses QDir::tempPath() to find such a location. It can be influenced by setting a platform specific environment variable. The following change set further extends this to also use application and company name in order to get app specific path, much like it is done by QSettings (this needs to be a bit tuned for the case with the standard runtime). >> >> I considered to allow overriding the location with a dedicated environment variable but I abandoned this idea as too dangerous - the location is subject to "rm -rf" and I do not want to imagine someone misunderstanding and setting it to $HOME or $PROJECTS or whatever valuable location :) >> >> Every project may have its specific constraints - I would rather let the user control the mechanism used. >> >> This also serves as a preparation step for adding support to receive updates for compiled-in resources (qrc). >> >> I am thinking maybe the overlay should be persistent by default? > > Lets see. > If you use a writeable location. Surely the changes are persistent. If you use a read only location then the changes would be currently not persistent and purged on remote runtime exit. > From the user perspective when he looks at the QML code of the remote workspace he would see in the read-only case his original source code and would not understand why the code behaves differently. Sure this is the opposite in the writeable workspace use case. > > After restarting the remote runtime in the read-only workspace use case the user would need to press publish all to sync its workspace again. > > So it might be just the question to automate this syncing. Either by announcing to the bench: The remote workspace is a read-only workspace, on re-connection please publish all automatically or the remove runtime request the sync automatically on startup and maybe this behavior could be omitted. > The other option would be to announce only to the bench that the workspace is read-only and we can add an action to auto-sync on connection to the target. Most flexibility but adds an option, I would prefer a good default behavior. > > So it seems I?m not in favor of persistent temporary data. And more in finding a transparent good default behavior for applying a sync on re-connect. > > > / jryannel > >> BR, >> Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kampas at jolla.com Mon Sep 5 08:29:45 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Mon, 5 Sep 2016 06:29:45 +0000 Subject: [Automotive] Sandboxing for System Installed Application In-Reply-To: <92D4EA6D-4761-4F1A-945E-58AD225AA392@pelagicore.com> References: <820C8AA4-CF58-4A38-990E-5052C26719CB@pelagicore.com> <597ECB6BFD23CC488EED8B6CD7566AD232F54A95@ORD2MBX01B.mex05.mlsrvr.com> <70EF4194-246A-466E-BF8B-94AD041ACC4B@pelagicore.com>, <92D4EA6D-4761-4F1A-945E-58AD225AA392@pelagicore.com> Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F5B81F@ORD2MBX01B.mex05.mlsrvr.com> Hi J?rgen, > So it seems I?m not in favor of persistent temporary data. And more in finding a transparent good default behavior for applying a sync on re-connect. I like that idea! I am quite sure I will come with patches implementing this kind of behavior. BR, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsanche1 at jaguarlandrover.com Mon Sep 5 22:39:28 2016 From: jsanche1 at jaguarlandrover.com (Sanchez, Jack) Date: Mon, 5 Sep 2016 13:39:28 -0700 Subject: [Automotive] QtIVI BackendType Switch/Registration Message-ID: Hi all, Working with the Qt Automotive Suite, running QtApplicationManager and using QtIVI. I'm currently working to implement the structure for switching the backends and I was curious if anyone had actually tried to do this yet. The documentation on this is very light and the behavior I'm experiencing feels counter intuitive. It seems that the "Simulator Plugin" in the QtIvi repository (and any installed service interfaces) is being registered as a Production backend by default and there seems to be no obvious way to tell the dynamic loader to switch to Simulation Backend type. The system seems to be setup such that I shouldn't need to manually operate the QIviServiceManager, however, as I'm investigating this backend switching functionality, it seems that I will have to in order to get the behavior I want. I feel like, in this example in QtIvi of the vehiclefunction_simulator plugin, I should be able to declare the object is a SimulationBackend. It would be great to hear if I'm missing something obvious, but either way I appreciate any feedback. Thanks! Best Regards, -- *Jack Sanchez* Lead Qt Engineer *E: jsanche1 at jaguarlandrover.com * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.holland at pelagicore.com Mon Sep 5 23:08:44 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Mon, 5 Sep 2016 23:08:44 +0200 Subject: [Automotive] QtIVI BackendType Switch/Registration In-Reply-To: References: Message-ID: Hi Jack, Am 05.09.16 um 22:39 schrieb Sanchez, Jack: > Hi all, > > Working with the Qt Automotive Suite, running QtApplicationManager and > using QtIVI. > > I'm currently working to implement the structure for switching the > backends and I was curious if anyone had actually tried to do this yet. > > The documentation on this is very light and the behavior I'm > experiencing feels counter intuitive. > > It seems that the "Simulator Plugin" in the QtIvi repository (and any > installed service interfaces) is being registered as a Production > backend by default and there seems to be no obvious way to tell the > dynamic loader to switch to Simulation Backend type. The current detection on whether a backend is a production backend or a simulation backend is done based on the file name. Once the backend contains the terms "_simulation" or "_simulator" it is currently detected as a simulation backend. Note there might be an issue in previous qtivi versions on this, which got fixed with this commit: 04cecf0f37af28b4b64e9575ca5ba9c6cfd26ea3 > > The system seems to be setup such that I shouldn't need to manually > operate the QIviServiceManager, however, as I'm investigating this > backend switching functionality, it seems that I will have to in order > to get the behavior I want. That could well be without exactly knowing the behavior you want ;-) The best would be, if you could describe what you would expect, or what you want to achieve, so we either know about a feature-gap or what to improve in the documentation > > I feel like, in this example in QtIvi of the vehiclefunction_simulator > plugin, I should be able to declare the object is a SimulationBackend. > > It would be great to hear if I'm missing something obvious, but either > way I appreciate any feedback. > > Thanks! > Best Regards, > > -- > *Jack Sanchez* > Lead Qt Engineer > *E: jsanche1 at jaguarlandrover.com * > Best Regards Dominik From jlamothe at docboxinc.com Fri Sep 9 23:07:43 2016 From: jlamothe at docboxinc.com (Jereme Lamothe) Date: Fri, 09 Sep 2016 21:07:43 +0000 Subject: [Automotive] Qt Automotive Suite & Ubuntu Message-ID: I got side tracked by other work, but wanted to write back to say I've successfully compiled / run both the Qt application manager and the neptune ui on Ubuntu Server 14.04. I noticed that a recent change relaxed the dbus requirements, thank you for that. After compiling + installing Wayland 1.10, Wayland protocols, and libyaml, I was able to build the Qt Wayland Compositor w/ Qt 5.7. Please note that this requires the latest hardware enablement stack to be installed (which satisfies an open gl version requirement). The compositor, and by extension the application manager, appears happy to run with an X11 back end ("startx /etc/X11/Xsession" and execute a script to run the neptune ui). I suspect the more typical use case w/ embedded hardware / a boot2qt image would have driver support to just run Wayland. I'm curious if anyone else has run the app manager in this manner (X11 backend)? Are there any known issues or technical concerns proceeding in this direction if the intent is to deploy on a full-sized Linux distro such as Ubuntu? -------------- next part -------------- An HTML attachment was scrubbed... URL: From 754833745 at qq.com Mon Sep 12 07:24:22 2016 From: 754833745 at qq.com (=?ISO-8859-1?B?TGFycnk=?=) Date: Mon, 12 Sep 2016 13:24:22 +0800 Subject: [Automotive] please add me in the mail list Message-ID: please add me in the mail list -------------- next part -------------- An HTML attachment was scrubbed... URL: From arasbm at gmail.com Tue Sep 13 00:31:34 2016 From: arasbm at gmail.com (Aras Balali Moghaddam) Date: Mon, 12 Sep 2016 15:31:34 -0700 Subject: [Automotive] What is the proper process for building for release with appman Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeiche at jaguarlandrover.com Thu Sep 15 00:18:23 2016 From: aeiche at jaguarlandrover.com (Eiche, Aaron) Date: Wed, 14 Sep 2016 15:18:23 -0700 Subject: [Automotive] appman IPC communication from System UI to app? Message-ID: Hi Everyone, I've been trying to implement IPC via appman ( http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager-applicationipcmanager.html) in one of our projects. I've managed to get communication going from one of our apps to our System UI, but I haven't been able to figure out how to implement the opposite direction. I would like to be able to make the System UI send information to an application. Am I missing something obvious here? Is there a practical reason why this isn't already implemented (some other method of accomplishing this) or it's a bad idea? thanks -Aaron E. -- *Aaron Eiche* Javascript Developer *T:* +1.971.256.9731 | *M: *+1.503.334.9164 Jaguar Land Rover North America, LLC 1419 NW 14th Ave, Portland, OR 97209 JaguarUSA.com | LandRoverUSA.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsanche1 at jaguarlandrover.com Thu Sep 15 00:47:19 2016 From: jsanche1 at jaguarlandrover.com (Sanchez, Jack) Date: Wed, 14 Sep 2016 15:47:19 -0700 Subject: [Automotive] Automotive Digest, Vol 16, Issue 3 In-Reply-To: References: Message-ID: Hi Dominik, Regarding the QtIVI behavior. I've been busy and didn't get a chance to send out here that I'd figured out my problem. So currently, it seems, with QtIVI - the QIviServiceManager will *not* register a given plugin as Simulation BackendType unless it is specifically labeled with "_simulation"; "_simulator" does not work. This isn't well documented that I had found and it wasn't until I had familiarized myself with the guts of the QIviServiceManager and saw the check in the private findServiceByInterface method that I found that answer. So I have been able to achieve the expected/desired behavior simply by having my plugin libs targeted as "lib_coollib_simulation" and any other name will be registered as a Production BackendType. Thanks for the response though! I do have another question for the folks out here! I've been trying to run GammaRay against our HMI system running appman. Worked my way around a few basic issues but now I find that appman segfaults when I launch with GammaRay under the different configuration options. The meta-boot2qt layer and Automotive Suite docs/release notes suggest this should be very obvious to do, but I suspect I'm missing another nuance with a config either on appman or the gammaray binaries. Thanks again! 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 * Business Details: Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3 4LF, UK Registered in England Number: 1672070 This e-mail and any attachments contain confidential information for a specific individual and purpose. The information is private and privileged and intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, please e-mail us immediately. We apologize for any inconvenience caused but you are hereby notified that any disclosure, copying or distribution or the taking of any action in reliance on the information contained herein is strictly prohibited. This e-mail does not constitute an order for goods or services unless accompanied by an official purchase order. On 14 September 2016 at 15:18, wrote: > Send Automotive mailing list submissions to > automotive at qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/automotive > or, via email, send a message with subject or body 'help' to > automotive-request at qt-project.org > > You can reach the person managing the list at > automotive-owner at qt-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Automotive digest..." > > > Today's Topics: > > 1. QtIVI BackendType Switch/Registration (Sanchez, Jack) > 2. Re: QtIVI BackendType Switch/Registration (Dominik Holland) > 3. Qt Automotive Suite & Ubuntu (Jereme Lamothe) > 4. please add me in the mail list ( Larry ) > 5. What is the proper process for building for release with > appman (Aras Balali Moghaddam) > 6. appman IPC communication from System UI to app? (Eiche, Aaron) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Sep 2016 13:39:28 -0700 > From: "Sanchez, Jack" > To: automotive at qt-project.org > Subject: [Automotive] QtIVI BackendType Switch/Registration > Message-ID: > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > > Working with the Qt Automotive Suite, running QtApplicationManager and > using QtIVI. > > I'm currently working to implement the structure for switching the backends > and I was curious if anyone had actually tried to do this yet. > > The documentation on this is very light and the behavior I'm experiencing > feels counter intuitive. > > It seems that the "Simulator Plugin" in the QtIvi repository (and any > installed service interfaces) is being registered as a Production backend > by default and there seems to be no obvious way to tell the dynamic loader > to switch to Simulation Backend type. > > The system seems to be setup such that I shouldn't need to manually operate > the QIviServiceManager, however, as I'm investigating this backend > switching functionality, it seems that I will have to in order to get the > behavior I want. > > I feel like, in this example in QtIvi of the vehiclefunction_simulator > plugin, I should be able to declare the object is a SimulationBackend. > > It would be great to hear if I'm missing something obvious, but either way > I appreciate any feedback. > > Thanks! > Best Regards, > > -- > *Jack Sanchez* > Lead Qt Engineer > *E: jsanche1 at jaguarlandrover.com * > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20160905/2d3ffda9/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Mon, 5 Sep 2016 23:08:44 +0200 > From: Dominik Holland > To: automotive at qt-project.org > Subject: Re: [Automotive] QtIVI BackendType Switch/Registration > Message-ID: > Content-Type: text/plain; charset=windows-1252 > > Hi Jack, > > Am 05.09.16 um 22:39 schrieb Sanchez, Jack: > > Hi all, > > > > Working with the Qt Automotive Suite, running QtApplicationManager and > > using QtIVI. > > > > I'm currently working to implement the structure for switching the > > backends and I was curious if anyone had actually tried to do this yet. > > > > The documentation on this is very light and the behavior I'm > > experiencing feels counter intuitive. > > > > It seems that the "Simulator Plugin" in the QtIvi repository (and any > > installed service interfaces) is being registered as a Production > > backend by default and there seems to be no obvious way to tell the > > dynamic loader to switch to Simulation Backend type. > > The current detection on whether a backend is a production backend or a > simulation backend is done based on the file name. Once the backend > contains the terms "_simulation" or "_simulator" it is currently > detected as a simulation backend. > > Note there might be an issue in previous qtivi versions on this, which > got fixed with this commit: 04cecf0f37af28b4b64e9575ca5ba9c6cfd26ea3 > > > > > The system seems to be setup such that I shouldn't need to manually > > operate the QIviServiceManager, however, as I'm investigating this > > backend switching functionality, it seems that I will have to in order > > to get the behavior I want. > > That could well be without exactly knowing the behavior you want ;-) > > The best would be, if you could describe what you would expect, or what > you want to achieve, so we either know about a feature-gap or what to > improve in the documentation > > > > > I feel like, in this example in QtIvi of the vehiclefunction_simulator > > plugin, I should be able to declare the object is a SimulationBackend. > > > > It would be great to hear if I'm missing something obvious, but either > > way I appreciate any feedback. > > > > Thanks! > > Best Regards, > > > > -- > > *Jack Sanchez* > > Lead Qt Engineer > > *E: jsanche1 at jaguarlandrover.com * > > > > Best Regards > Dominik > > > > ------------------------------ > > Message: 3 > Date: Fri, 09 Sep 2016 21:07:43 +0000 > From: Jereme Lamothe > To: "automotive at qt-project.org" > Subject: [Automotive] Qt Automotive Suite & Ubuntu > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > I got side tracked by other work, but wanted to write back to say I've > successfully compiled / run both the Qt application manager and the neptune > ui on Ubuntu Server 14.04. I noticed that a recent change relaxed the dbus > requirements, thank you for that. After compiling + installing Wayland > 1.10, Wayland protocols, and libyaml, I was able to build the Qt Wayland > Compositor w/ Qt 5.7. Please note that this requires the latest hardware > enablement stack to be installed (which satisfies an open gl version > requirement). > > The compositor, and by extension the application manager, appears happy to > run with an X11 back end ("startx /etc/X11/Xsession" and execute a script > to run the neptune ui). I suspect the more typical use case w/ embedded > hardware / a boot2qt image would have driver support to just run Wayland. > I'm > curious if anyone else has run the app manager in this manner (X11 > backend)? Are there any known issues or technical concerns proceeding in > this direction if the intent is to deploy on a full-sized Linux distro such > as Ubuntu? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20160909/ef6bca5a/attachment-0001.html> > > ------------------------------ > > Message: 4 > Date: Mon, 12 Sep 2016 13:24:22 +0800 > From: " Larry " <754833745 at qq.com> > To: " automotive " > Subject: [Automotive] please add me in the mail list > Message-ID: > Content-Type: text/plain; charset="iso-8859-1" > > please add me in the mail list > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20160912/7a32ecb5/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Mon, 12 Sep 2016 15:31:34 -0700 > From: Aras Balali Moghaddam > To: Qt Automotive List > Subject: [Automotive] What is the proper process for building for > release with appman > Message-ID: > com> > Content-Type: text/plain; charset="utf-8" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20160912/0d27fdf3/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Wed, 14 Sep 2016 15:18:23 -0700 > From: "Eiche, Aaron" > To: automotive at qt-project.org > Subject: [Automotive] appman IPC communication from System UI to app? > Message-ID: > aU4OHejdd7ZQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Everyone, > > I've been trying to implement IPC via appman ( > http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager- > applicationipcmanager.html) > in one of our projects. I've managed to get communication going from one of > our apps to our System UI, but I haven't been able to figure out how to > implement the opposite direction. I would like to be able to make the > System UI send information to an application. > > Am I missing something obvious here? Is there a practical reason why this > isn't already implemented (some other method of accomplishing this) or it's > a bad idea? > > thanks > -Aaron E. > > -- > *Aaron Eiche* > Javascript Developer > > *T:* +1.971.256.9731 | *M: *+1.503.334.9164 > > > > Jaguar Land Rover North America, LLC > 1419 NW 14th Ave, Portland, OR 97209 > JaguarUSA.com | LandRoverUSA.com > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20160914/135c706e/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > > > ------------------------------ > > End of Automotive Digest, Vol 16, Issue 3 > ***************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.holland at pelagicore.com Thu Sep 15 09:51:07 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Thu, 15 Sep 2016 09:51:07 +0200 Subject: [Automotive] Automotive Digest, Vol 16, Issue 3 In-Reply-To: References: Message-ID: <9bb3989a-d876-34a2-6cda-b966a461a539@pelagicore.com> Hi Jack, Am 09/15/2016 um 12:47 AM schrieb Sanchez, Jack: > Hi Dominik, > > Regarding the QtIVI behavior. > > I've been busy and didn't get a chance to send out here that I'd figured > out my problem. > > So currently, it seems, with QtIVI - the QIviServiceManager will *not* > register a given plugin as Simulation BackendType unless it is > specifically labeled with "_simulation"; "_simulator" does not work. > This isn't well documented that I had found and it wasn't until I had > familiarized myself with the guts of the QIviServiceManager and saw the > check in the private findServiceByInterface method that I found that answer. > > So I have been able to achieve the expected/desired behavior simply by > having my plugin libs targeted as "lib_coollib_simulation" and any other > name will be registered as a Production BackendType. Thx for the feedback, i added a bugreport for this: https://bugreports.qt.io/browse/AUTOSUITE-9 > > Thanks for the response though! > > I do have another question for the folks out here! > > I've been trying to run GammaRay against our HMI system running appman. > Worked my way around a few basic issues but now I find that appman > segfaults when I launch with GammaRay under the different configuration > options. The meta-boot2qt layer and Automotive Suite docs/release notes > suggest this should be very obvious to do, but I suspect I'm missing > another nuance with a config either on appman or the gammaray binaries. i think it would make sense to begin a new thread about this issue, otherwise you might get no answer Dominik > > Thanks again! > > 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 * > > Business Details: > Jaguar Land Rover Limited, Abbey Road, Whitley, Coventry CV3 4LF, UK > Registered in England Number: 1672070 > > This e-mail and any attachments contain confidential information for a > specific individual and purpose. The information is private and > privileged and intended solely for the use of the individual to whom it > is addressed. If you are not the intended recipient, please e-mail us > immediately. We apologize for any inconvenience caused but you are > hereby notified that any disclosure, copying or distribution or the > taking of any action in reliance on the information contained herein is > strictly prohibited. > > This e-mail does not constitute an order for goods or services unless > accompanied by an official purchase order. > > On 14 September 2016 at 15:18, > wrote: > > Send Automotive mailing list submissions to > automotive at qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/automotive > > or, via email, send a message with subject or body 'help' to > automotive-request at qt-project.org > > > You can reach the person managing the list at > automotive-owner at qt-project.org > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Automotive digest..." > > > Today's Topics: > > 1. QtIVI BackendType Switch/Registration (Sanchez, Jack) > 2. Re: QtIVI BackendType Switch/Registration (Dominik Holland) > 3. Qt Automotive Suite & Ubuntu (Jereme Lamothe) > 4. please add me in the mail list ( Larry ) > 5. What is the proper process for building for release with > appman (Aras Balali Moghaddam) > 6. appman IPC communication from System UI to app? (Eiche, Aaron) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Sep 2016 13:39:28 -0700 > From: "Sanchez, Jack" > > To: automotive at qt-project.org > Subject: [Automotive] QtIVI BackendType Switch/Registration > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Hi all, > > Working with the Qt Automotive Suite, running QtApplicationManager and > using QtIVI. > > I'm currently working to implement the structure for switching the > backends > and I was curious if anyone had actually tried to do this yet. > > The documentation on this is very light and the behavior I'm > experiencing > feels counter intuitive. > > It seems that the "Simulator Plugin" in the QtIvi repository (and any > installed service interfaces) is being registered as a Production > backend > by default and there seems to be no obvious way to tell the dynamic > loader > to switch to Simulation Backend type. > > The system seems to be setup such that I shouldn't need to manually > operate > the QIviServiceManager, however, as I'm investigating this backend > switching functionality, it seems that I will have to in order to > get the > behavior I want. > > I feel like, in this example in QtIvi of the vehiclefunction_simulator > plugin, I should be able to declare the object is a SimulationBackend. > > It would be great to hear if I'm missing something obvious, but > either way > I appreciate any feedback. > > Thanks! > Best Regards, > > -- > *Jack Sanchez* > Lead Qt Engineer > *E: jsanche1 at jaguarlandrover.com > >* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > Message: 2 > Date: Mon, 5 Sep 2016 23:08:44 +0200 > From: Dominik Holland > > To: automotive at qt-project.org > Subject: Re: [Automotive] QtIVI BackendType Switch/Registration > Message-ID: > > Content-Type: text/plain; charset=windows-1252 > > Hi Jack, > > Am 05.09.16 um 22:39 schrieb Sanchez, Jack: > > Hi all, > > > > Working with the Qt Automotive Suite, running QtApplicationManager and > > using QtIVI. > > > > I'm currently working to implement the structure for switching the > > backends and I was curious if anyone had actually tried to do this > yet. > > > > The documentation on this is very light and the behavior I'm > > experiencing feels counter intuitive. > > > > It seems that the "Simulator Plugin" in the QtIvi repository (and any > > installed service interfaces) is being registered as a Production > > backend by default and there seems to be no obvious way to tell the > > dynamic loader to switch to Simulation Backend type. > > The current detection on whether a backend is a production backend or a > simulation backend is done based on the file name. Once the backend > contains the terms "_simulation" or "_simulator" it is currently > detected as a simulation backend. > > Note there might be an issue in previous qtivi versions on this, which > got fixed with this commit: 04cecf0f37af28b4b64e9575ca5ba9c6cfd26ea3 > > > > > The system seems to be setup such that I shouldn't need to manually > > operate the QIviServiceManager, however, as I'm investigating this > > backend switching functionality, it seems that I will have to in order > > to get the behavior I want. > > That could well be without exactly knowing the behavior you want ;-) > > The best would be, if you could describe what you would expect, or what > you want to achieve, so we either know about a feature-gap or what to > improve in the documentation > > > > > I feel like, in this example in QtIvi of the vehiclefunction_simulator > > plugin, I should be able to declare the object is a SimulationBackend. > > > > It would be great to hear if I'm missing something obvious, but either > > way I appreciate any feedback. > > > > Thanks! > > Best Regards, > > > > -- > > *Jack Sanchez* > > Lead Qt Engineer > > *E: jsanche1 at jaguarlandrover.com > > >* > > > > Best Regards > Dominik > > > > ------------------------------ > > Message: 3 > Date: Fri, 09 Sep 2016 21:07:43 +0000 > From: Jereme Lamothe > > To: "automotive at qt-project.org " > > > Subject: [Automotive] Qt Automotive Suite & Ubuntu > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > I got side tracked by other work, but wanted to write back to say I've > successfully compiled / run both the Qt application manager and the > neptune > ui on Ubuntu Server 14.04. I noticed that a recent change relaxed > the dbus > requirements, thank you for that. After compiling + installing Wayland > 1.10, Wayland protocols, and libyaml, I was able to build the Qt Wayland > Compositor w/ Qt 5.7. Please note that this requires the latest hardware > enablement stack to be installed (which satisfies an open gl version > requirement). > > The compositor, and by extension the application manager, appears > happy to > run with an X11 back end ("startx /etc/X11/Xsession" and execute a > script > to run the neptune ui). I suspect the more typical use case w/ embedded > hardware / a boot2qt image would have driver support to just run > Wayland. I'm > curious if anyone else has run the app manager in this manner (X11 > backend)? Are there any known issues or technical concerns proceeding in > this direction if the intent is to deploy on a full-sized Linux > distro such > as Ubuntu? > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > Message: 4 > Date: Mon, 12 Sep 2016 13:24:22 +0800 > From: " Larry " <754833745 at qq.com > > To: " automotive " > > Subject: [Automotive] please add me in the mail list > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > please add me in the mail list > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > Message: 5 > Date: Mon, 12 Sep 2016 15:31:34 -0700 > From: Aras Balali Moghaddam > > To: Qt Automotive List > > Subject: [Automotive] What is the proper process for building for > release with appman > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > Message: 6 > Date: Wed, 14 Sep 2016 15:18:23 -0700 > From: "Eiche, Aaron" > > To: automotive at qt-project.org > Subject: [Automotive] appman IPC communication from System UI to app? > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Hi Everyone, > > I've been trying to implement IPC via appman ( > http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager-applicationipcmanager.html > ) > in one of our projects. I've managed to get communication going from > one of > our apps to our System UI, but I haven't been able to figure out how to > implement the opposite direction. I would like to be able to make the > System UI send information to an application. > > Am I missing something obvious here? Is there a practical reason why > this > isn't already implemented (some other method of accomplishing this) > or it's > a bad idea? > > thanks > -Aaron E. > > -- > *Aaron Eiche* > Javascript Developer > > *T:* +1.971.256.9731 | *M: *+1.503.334.9164 > > > > Jaguar Land Rover North America, LLC > 1419 NW 14th Ave, Portland, OR 97209 > JaguarUSA.com > | LandRoverUSA.com > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > > > > ------------------------------ > > End of Automotive Digest, Vol 16, Issue 3 > ***************************************** > > > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holland at pelagicore.com www.pelagicore.com From vladstelmahovsky at gmail.com Thu Sep 15 10:55:46 2016 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Thu, 15 Sep 2016 10:55:46 +0200 Subject: [Automotive] Native apps Message-ID: Hi is there is a plans to implement native (C++) apps to be started by appman? thanks -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladstelmahovsky at gmail.com Thu Sep 15 13:12:50 2016 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Thu, 15 Sep 2016 13:12:50 +0200 Subject: [Automotive] What is the proper process for building for release with appman In-Reply-To: References: Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.griebl at pelagicore.com Thu Sep 15 14:13:56 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Thu, 15 Sep 2016 14:13:56 +0200 Subject: [Automotive] Native apps In-Reply-To: References: Message-ID: <4a1f7be6-d68e-bbda-49b6-78fa3b83d164@pelagicore.com> Hi Vlad, On 15.09.2016 10:55, Vlad Stelmahovsky wrote: > is there is a plans to implement native (C++) apps to be started by appman? > thanks Just set "runtime: native" in your info.yaml See the runtime field documentation here: https://doc.qt.io/QtApplicationManager/manifest.html cu Robert -- Robert Griebl SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From alistair.adams at qt.io Thu Sep 15 14:38:52 2016 From: alistair.adams at qt.io (Alistair Adams) Date: Thu, 15 Sep 2016 12:38:52 +0000 Subject: [Automotive] Native apps In-Reply-To: References: Message-ID: Yes, very much so. This is key to being able to integrate non Qt apps. -Alistair From: Automotive [mailto:automotive-bounces+alistair.adams=qt.io at qt-project.org] On Behalf Of Vlad Stelmahovsky Sent: Thursday, September 15, 2016 1:56 AM To: automotive Subject: [Automotive] Native apps Hi is there is a plans to implement native (C++) apps to be started by appman? thanks -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From nedim.hadzic at pelagicore.com Thu Sep 15 14:57:05 2016 From: nedim.hadzic at pelagicore.com (Nedim Hadzic) Date: Thu, 15 Sep 2016 14:57:05 +0200 Subject: [Automotive] appman IPC communication from System UI to app? In-Reply-To: References: Message-ID: Hello Aaron, It is possible to send signals from System UI to an app. I created one example for you in the attachment using the System UI example from link you provided http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager- applicationipcmanager.html. I simply added the interface on the application side to handle triggering 'testSignal' from System UI. You can also find one example in the music application in the Neptune UI ( https://codereview.qt-project.org/#/admin/projects/qt-apps/neptune-ui). I hope this helps you and let me know if you have more questions. Kind regards, On 15 September 2016 at 00:18, Eiche, Aaron wrote: > Hi Everyone, > > I've been trying to implement IPC via appman (http://doc.qt.io/ > QtApplicationManager/qml-qtapplicationmanager-applicationipcmanager.html) > in one of our projects. I've managed to get communication going from one of > our apps to our System UI, but I haven't been able to figure out how to > implement the opposite direction. I would like to be able to make the > System UI send information to an application. > > Am I missing something obvious here? Is there a practical reason why this > isn't already implemented (some other method of accomplishing this) or it's > a bad idea? > > thanks > -Aaron E. > > -- > *Aaron Eiche* > Javascript Developer > > *T:* +1.971.256.9731 | *M: *+1.503.334.9164 > > > > Jaguar Land Rover North America, LLC > 1419 NW 14th Ave, Portland, OR 97209 > JaguarUSA.com | LandRoverUSA.com > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > > -- Nedim Hadzic Senior Software Engineer Pelagicore AG +49 151 655 666 77 pelagicore.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ---------------------------------- SYSTEM UI ---------------------------------- import QtQuick 2.0 import QtApplicationManager 1.0 ApplicationIPCInterface { id: extension property bool pbool: true property double pdouble: 3.14 signal testSignal(string str, variant list) readonly property var _decltype_testFunction: { "void": [ "int", "string" ] } function testFunction(foo, bar) { console.log("testFunction was called: " + foo + " " + bar) } Component.onCompleted: { ApplicationIPCManager.registerInterface(extension, "io.qt.test.interface", { "capabilities": [ "media", "camera" ] }) } } ---------------------------------- APP ---------------------------------- import QtQuick 2.0 import QtApplicationManager 1.0 Item { id: root property bool pbool: flase property Item ipc: Item { ApplicationInterfaceExtension { id: interfaceRemoteControl name: "io.qt.test.interface" } Binding { target: interfaceRemoteControl.object; property: "pbool"; value: root.pbool } Connections { target: interfaceRemoteControl.object onTestSignal: { console.log("testSignal triggered from the SystemUI", str, list) } } } } From robert.griebl at pelagicore.com Thu Sep 15 15:33:13 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Thu, 15 Sep 2016 15:33:13 +0200 Subject: [Automotive] appman IPC communication from System UI to app? In-Reply-To: References: Message-ID: <829353d5-662a-1315-48ac-9ab70dac4c36@pelagicore.com> Hi Aaron, On 15.09.2016 00:18, Eiche, Aaron wrote: > I've been trying to implement IPC via appman > (http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager-applicationipcmanager.html) > in one of our projects. I've managed to get communication going from one > of our apps to our System UI, but I haven't been able to figure out how > to implement the opposite direction. I would like to be able to make the > System UI send information to an application. > > Am I missing something obvious here? Is there a practical reason why > this isn't already implemented (some other method of accomplishing this) > or it's a bad idea? This IPC is a 1:n remote-object connection between the system-UI and apps. You register a QtObject on the system-ui side an then: - every property will be synced between all apps and the system-ui, regardless of which side changes the property - every signal you emit on the system-ui side will be also emitted in each app as well - calling a function from an app will actually execute the function within the system-ui. cu Robert -- Robert Griebl SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From arasbm at gmail.com Thu Sep 15 18:26:57 2016 From: arasbm at gmail.com (Aras Balali Moghaddam) Date: Thu, 15 Sep 2016 09:26:57 -0700 Subject: [Automotive] What is the proper process for building for release with appman In-Reply-To: References: Message-ID: 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 to this API document 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 < vladstelmahovsky at gmail.com> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.holland at pelagicore.com Thu Sep 15 19:57:22 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Thu, 15 Sep 2016 19:57:22 +0200 Subject: [Automotive] What is the proper process for building for release with appman In-Reply-To: References: Message-ID: <32fa557a-6449-c2ef-bb44-3d10c487a35e@pelagicore.com> 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 > 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 > From 754833745 at qq.com Mon Sep 26 09:25:34 2016 From: 754833745 at qq.com (=?ISO-8859-1?B?TGFycnk=?=) Date: Mon, 26 Sep 2016 15:25:34 +0800 Subject: [Automotive] Automotive Digest, Vol 16, Issue 6 In-Reply-To: References: Message-ID: Hi I want to know How to install qt 3d scene editor? Thanks for any help! Larry ------------------ Original ------------------ From: "automotive-request";; Date: Thu, Sep 15, 2016 09:33 PM To: "automotive"; Subject: Automotive Digest, Vol 16, Issue 6 Send Automotive mailing list submissions to automotive at qt-project.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.qt-project.org/mailman/listinfo/automotive or, via email, send a message with subject or body 'help' to automotive-request at qt-project.org You can reach the person managing the list at automotive-owner at qt-project.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Automotive digest..." Today's Topics: 1. Re: Native apps (Robert Griebl) 2. Re: Native apps (Alistair Adams) 3. Re: appman IPC communication from System UI to app? (Nedim Hadzic) 4. Re: appman IPC communication from System UI to app? (Robert Griebl) ---------------------------------------------------------------------- Message: 1 Date: Thu, 15 Sep 2016 14:13:56 +0200 From: Robert Griebl To: automotive at qt-project.org Subject: Re: [Automotive] Native apps Message-ID: <4a1f7be6-d68e-bbda-49b6-78fa3b83d164 at pelagicore.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Hi Vlad, On 15.09.2016 10:55, Vlad Stelmahovsky wrote: > is there is a plans to implement native (C++) apps to be started by appman? > thanks Just set "runtime: native" in your info.yaml See the runtime field documentation here: https://doc.qt.io/QtApplicationManager/manifest.html cu Robert -- Robert Griebl SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com ------------------------------ Message: 2 Date: Thu, 15 Sep 2016 12:38:52 +0000 From: Alistair Adams To: Vlad Stelmahovsky , automotive Subject: Re: [Automotive] Native apps Message-ID: Content-Type: text/plain; charset="utf-8" Yes, very much so. This is key to being able to integrate non Qt apps. -Alistair From: Automotive [mailto:automotive-bounces+alistair.adams=qt.io at qt-project.org] On Behalf Of Vlad Stelmahovsky Sent: Thursday, September 15, 2016 1:56 AM To: automotive Subject: [Automotive] Native apps Hi is there is a plans to implement native (C++) apps to be started by appman? thanks -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 15 Sep 2016 14:57:05 +0200 From: Nedim Hadzic To: "Eiche, Aaron" Cc: Qt Automotive List Subject: Re: [Automotive] appman IPC communication from System UI to app? Message-ID: Content-Type: text/plain; charset="utf-8" Hello Aaron, It is possible to send signals from System UI to an app. I created one example for you in the attachment using the System UI example from link you provided http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager- applicationipcmanager.html. I simply added the interface on the application side to handle triggering 'testSignal' from System UI. You can also find one example in the music application in the Neptune UI ( https://codereview.qt-project.org/#/admin/projects/qt-apps/neptune-ui). I hope this helps you and let me know if you have more questions. Kind regards, On 15 September 2016 at 00:18, Eiche, Aaron wrote: > Hi Everyone, > > I've been trying to implement IPC via appman (http://doc.qt.io/ > QtApplicationManager/qml-qtapplicationmanager-applicationipcmanager.html) > in one of our projects. I've managed to get communication going from one of > our apps to our System UI, but I haven't been able to figure out how to > implement the opposite direction. I would like to be able to make the > System UI send information to an application. > > Am I missing something obvious here? Is there a practical reason why this > isn't already implemented (some other method of accomplishing this) or it's > a bad idea? > > thanks > -Aaron E. > > -- > *Aaron Eiche* > Javascript Developer > > *T:* +1.971.256.9731 | *M: *+1.503.334.9164 > > > > Jaguar Land Rover North America, LLC > 1419 NW 14th Ave, Portland, OR 97209 > JaguarUSA.com | LandRoverUSA.com > > > _______________________________________________ > Automotive mailing list > Automotive at qt-project.org > http://lists.qt-project.org/mailman/listinfo/automotive > > -- Nedim Hadzic Senior Software Engineer Pelagicore AG +49 151 655 666 77 pelagicore.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- ---------------------------------- SYSTEM UI ---------------------------------- import QtQuick 2.0 import QtApplicationManager 1.0 ApplicationIPCInterface { id: extension property bool pbool: true property double pdouble: 3.14 signal testSignal(string str, variant list) readonly property var _decltype_testFunction: { "void": [ "int", "string" ] } function testFunction(foo, bar) { console.log("testFunction was called: " + foo + " " + bar) } Component.onCompleted: { ApplicationIPCManager.registerInterface(extension, "io.qt.test.interface", { "capabilities": [ "media", "camera" ] }) } } ---------------------------------- APP ---------------------------------- import QtQuick 2.0 import QtApplicationManager 1.0 Item { id: root property bool pbool: flase property Item ipc: Item { ApplicationInterfaceExtension { id: interfaceRemoteControl name: "io.qt.test.interface" } Binding { target: interfaceRemoteControl.object; property: "pbool"; value: root.pbool } Connections { target: interfaceRemoteControl.object onTestSignal: { console.log("testSignal triggered from the SystemUI", str, list) } } } } ------------------------------ Message: 4 Date: Thu, 15 Sep 2016 15:33:13 +0200 From: Robert Griebl To: automotive at qt-project.org Subject: Re: [Automotive] appman IPC communication from System UI to app? Message-ID: <829353d5-662a-1315-48ac-9ab70dac4c36 at pelagicore.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Hi Aaron, On 15.09.2016 00:18, Eiche, Aaron wrote: > I've been trying to implement IPC via appman > (http://doc.qt.io/QtApplicationManager/qml-qtapplicationmanager-applicationipcmanager.html) > in one of our projects. I've managed to get communication going from one > of our apps to our System UI, but I haven't been able to figure out how > to implement the opposite direction. I would like to be able to make the > System UI send information to an application. > > Am I missing something obvious here? Is there a practical reason why > this isn't already implemented (some other method of accomplishing this) > or it's a bad idea? This IPC is a 1:n remote-object connection between the system-UI and apps. You register a QtObject on the system-ui side an then: - every property will be synced between all apps and the system-ui, regardless of which side changes the property - every signal you emit on the system-ui side will be also emitted in each app as well - calling a function from an app will actually execute the function within the system-ui. cu Robert -- Robert Griebl SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com ------------------------------ Subject: Digest Footer _______________________________________________ Automotive mailing list Automotive at qt-project.org http://lists.qt-project.org/mailman/listinfo/automotive ------------------------------ End of Automotive Digest, Vol 16, Issue 6 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.kampas at jolla.com Mon Sep 26 12:11:29 2016 From: martin.kampas at jolla.com (Martin Kampas) Date: Mon, 26 Sep 2016 10:11:29 +0000 Subject: [Automotive] QmlLive: What is the official naming? Message-ID: <597ECB6BFD23CC488EED8B6CD7566AD232F5E419@ORD2MBX01B.mex05.mlsrvr.com> 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 jeremiah.foster at pelagicore.com Thu Sep 29 04:13:11 2016 From: jeremiah.foster at pelagicore.com (Jeremiah Foster) Date: Wed, 28 Sep 2016 22:13:11 -0400 Subject: [Automotive] GENIVI Qt AS spin Message-ID: Hi, This is just a quick note to let this list know about the GENIVI developer platform Qt AS spin: https://at.projects.genivi.org/wiki/display/GDP/GDP+Qt+AS+spin The GDP Qt AS spin is designed to provide a stunning interface to what has traditionally been a fairly staid developer offering, as well as demonstrate integration patterns to the underlying middleware automotive APIs designed by OEMs and Tier 1s. Like GENIVI software and Qt, this is a free software offering. Contributing to the spin can be done through the Qt project itself, through Qt AS, or through GENIVI's software components: https://github.com/GENIVI Thank you, Jeremiah -- Jeremiah C. Foster GENIVI COMMUNITY MANAGER Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden M: +1.860.772.9242 jeremiah.foster at pelagicore.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PELAGICORE_RGB_Black_horizontal.png Type: image/png Size: 11841 bytes Desc: not available URL: