Hi Wim

I wouldn't get phased by the 2 Virtual machines. They are just unix boxes, and if you know your way around Ubuuntu, then they should not be too strange.

I suggest you did as I did a few nights ago, connect to both with SSH (just like you would connect to a real remote Unix machine), and spend sometime snooping around the directory structures to get a feel for the lay of the land. You can use standard unix tools like GREP to search ...

Chris


Zitat von "Wim de Vries" <wsvr...@xs4all.nl>:

christopher.l...@thurweb.ch schreef op 2013-04-16 23:05:
HI Wim

If I have correctly understood you, you actually have 2 projects:

a) the source of the QtSerialPort project
Yes.
b) your own project pilotnavigator
Yes.

Have you tried building QtSerialPort targeting the SailfishOS?

If so, what ends up (if anything) in the Sailfish SDK and Emulator VMs?
I am just concentrating on the MER SDK for now.
Building the QtSerialPort project goes without errors.
But I haven't yet found out where the libs and headers did end up.
(I am not very experienced on VMs:
due to the directory mapping between host and VM it's hard to determine what is living on which (virtual) machine)
Building pilotnavigator fails because QtSerial headers are not found.

Depending on this, you may or may not need to deploy something to one
or both in order to build and run your pilotnavigator project which
imports QtSerialPort.
Yes, but where and how can I deploy QtSerialport on both VMs?
But stepping back a bit: are you actually asking the right question?
Why are you going the serial port route for Sailfish devices?
I have to read/write from/to a pressure (for altitude), temperature and humidity sensor.
QtSerialPort allows some non-blocking reading etc..

We don't know yet what they will look like, but I doubt that most
will  have a physical serial port. (though not having looked deep into
QtSerialPort, it is possible that a physical port is not required).
The device is via USB, communication is serial (well supported in Linux).

If you want to connect to something like this: (shameless plug for
Swiss technology)
http://www.flytec.ch/de/produkte/fluginstrumente/sensbox/uebersicht.html
then maybe the QtMobility Connectivity Bluetooth api may be an
interesting option.
For safety reasons: a cable is much more secure than bluetooth,
not mentioning interference with radio and transponder, and regulations.

And then my guess is that many Sailfish devices will have an internal
GPS, also supported by Qt Mobility.
True. Pilotnavigator allows both external and internal GPS.
External GPS device can be placed in a suitable place for optimal receival.

And if it doesn't work, just go flying.

Ciao

Chris

p.s how are the thermals in Holland? We had the first real credible
thermals this weekend, and boy were they wonderful and so well
deserved after such a long winter ...And in 15 years of flying, I
don't think I have ever been able to do a top-landing in snow before!
I fly MLA nowadays, but I still use thermals to save fuel (not appreciated by other motorized pliots!)



Zitat von "Wim de Vries" <wsvr...@xs4all.nl>:

My application is an aircraft navigation system (open source, see https://sourceforge.net/projects/pilotnavigator/), currently running on Ubuntu.
I have one QGLWidget and physically next to that a GUI QtWidget.
Mainwindow is also a QtWidget.
I stumbled on this C++ issue when I posted a question on how to use the QtSerialPort (for gps and pressure sensors) module within Sailfish. I do want to port the GUI to QML somewhere in time (I have done some testing: huge amount of work), but I first want to test the application on Sailfish as it is now. I do use the pro file of the current project, but I have to add the QtSerialPort to the (Mer?) SDK before I can build the project. On Ubuntu I just build the .pro file of QtSerialPort with the current qmake, and the libs, headers, etc. end up nicely within the SDK, ready to be used for new projects.
Any advice appreciated.
Thanks.



On 04/15/2013 08:12 AM, Jonni Rainisto wrote:

Nothing prevents you from using C++ only, but having said that its usually only fullscreen opengles2 games that goes with that approach.

Usually you just make QtQuick application, where you do UI part with QML and backend part in C++ aka. hybrid app. I would encourage to go this way, of course depending what kind of application you are doing (you didn't mention if you application if fullscreen opengles2 game).

If you have existing C++ project, then its just enough for you to open the existing .pro file with creator, you don't have to use the wizard to make a new project. Drawback is that look and feel wont be consistent with other applications if you don't use the QML Sailfish components for the UI.

re, Jonni

On 04/14/2013 11:48 PM, Wim de Vries wrote:
Hi,
My project is C++.
It looks like Sailfish is only Qt Quick (new project only allows this option).
Is C++ a no-go for sailfish?
If not, how do I proceed.
Thanks.
_______________________________________________
SailfishOS.org Devel mailing list

_______________________________________________
SailfishOS.org Devel mailing list


_______________________________________________
SailfishOS.org Devel mailing list





_______________________________________________
SailfishOS.org Devel mailing list

Reply via email to