QiJSBSim started out as simply a vehicle to use the QFlightInstruments PFD, driven by JSBSim. At first I built JSBSim into the app, but I didn't have a high-res timer, so JSBSim ran too slow. I then had a choice - add a high-res timer, or run JSBSim as a separate process and communicate with it over sockets. JSBSim already had some socket communication built in to it, but I added some new communication types more suited to what I needed for QtJSBSim. At this point QtJSBSim became more of a technology demonstrator for the two-way UDP communications. I could go back to the "build-in" method of running JSBSim, but the interprocess communication method is intriguing enough that I'll keep using it. I'd like to find out what are the limits of its usefulness.
So, what next? Build an OTW (out the window) viewer with OpenGL? Add more aircraft types? Integrate with other GPL projects, like FlightGear? Maybe build in an HLA federate class? Whatever I add will mean a lot of new code, which will bury the simplicity of this Qt app, and that simplicity is its best feature. Probably the biggest challenge going forward will be using OOP principles to move code out of the QMainWindow class to keep it from turning into a monster. This is my first "official" Qt project, so I'm learning Qt as I go along, and one thing I've learned is that the QMainWindow class (where all the action is) can really grow! So, there are challenges, but progress marches on.
This is where Elias comes in, whom I have added as a developer of this project. I'll let Elias introduce himself. He extended QtJSBSim in a very interesting way, adding an autopilot between this app and JSBSim, and also using JSBSim's built-in FlightGear interface to use FlightGear as a viewer.
I suppose the main thing to consider about QtJSBSim is that it's a Qt project, which means: 1) It'll always have a GPL license, 2) It's meant to be open source, using Qt Creator for rapid development, and 3) It'll probably never be finished, and I mean that in a good way.
-- Dave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dave, now im trying to make interface more graphic than text. So i try to add something like HUD. Still in progress. I read quickly about OTW that is being used in OpenEaagles. If so, it is a good idea to incorporate that option in QtJSBSim though it may demand a lot of time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dave, i successfully added joystick's and throttle rulers and some additional info (like rpm's) at the PFD, which was my first step goal. However, scaling doesn't work well. So im working on it. Then, the idea about OTW appeared to me very interesting, and i got some code of OTW from OpenEaggles. It was compiled with a very old OSG version, so i rebuilt it and now trying to incorporate it into QtJSBSim. Some OSG coding is also required. Though it adds new external 3rdParty dependencies i think that 3D viewer and controller are worth of it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
QiJSBSim started out as simply a vehicle to use the QFlightInstruments PFD, driven by JSBSim. At first I built JSBSim into the app, but I didn't have a high-res timer, so JSBSim ran too slow. I then had a choice - add a high-res timer, or run JSBSim as a separate process and communicate with it over sockets. JSBSim already had some socket communication built in to it, but I added some new communication types more suited to what I needed for QtJSBSim. At this point QtJSBSim became more of a technology demonstrator for the two-way UDP communications. I could go back to the "build-in" method of running JSBSim, but the interprocess communication method is intriguing enough that I'll keep using it. I'd like to find out what are the limits of its usefulness.
So, what next? Build an OTW (out the window) viewer with OpenGL? Add more aircraft types? Integrate with other GPL projects, like FlightGear? Maybe build in an HLA federate class? Whatever I add will mean a lot of new code, which will bury the simplicity of this Qt app, and that simplicity is its best feature. Probably the biggest challenge going forward will be using OOP principles to move code out of the QMainWindow class to keep it from turning into a monster. This is my first "official" Qt project, so I'm learning Qt as I go along, and one thing I've learned is that the QMainWindow class (where all the action is) can really grow! So, there are challenges, but progress marches on.
This is where Elias comes in, whom I have added as a developer of this project. I'll let Elias introduce himself. He extended QtJSBSim in a very interesting way, adding an autopilot between this app and JSBSim, and also using JSBSim's built-in FlightGear interface to use FlightGear as a viewer.
I suppose the main thing to consider about QtJSBSim is that it's a Qt project, which means: 1) It'll always have a GPL license, 2) It's meant to be open source, using Qt Creator for rapid development, and 3) It'll probably never be finished, and I mean that in a good way.
-- Dave
Dave, now im trying to make interface more graphic than text. So i try to add something like HUD. Still in progress. I read quickly about OTW that is being used in OpenEaagles. If so, it is a good idea to incorporate that option in QtJSBSim though it may demand a lot of time.
Dave, i successfully added joystick's and throttle rulers and some additional info (like rpm's) at the PFD, which was my first step goal. However, scaling doesn't work well. So im working on it. Then, the idea about OTW appeared to me very interesting, and i got some code of OTW from OpenEaggles. It was compiled with a very old OSG version, so i rebuilt it and now trying to incorporate it into QtJSBSim. Some OSG coding is also required. Though it adds new external 3rdParty dependencies i think that 3D viewer and controller are worth of it.