Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Paul Surgeon wrote: I would love to see all the FG core stuff going that route - one network capable API that everything can work through including FG itself. As far as I can see FG looks like it's already half way there. I have been working on extending the property code to add an SGRemoteProperty class to access properties on a remote host instead of locally. Most of the tree is cached locally, but queering the value of the end-node is done through a socket connection. I have this sort of working (but need more debugging). Unfortunately I got detracted by political issues (which went great BTW. It looks like my local airport is saved) and didn't do much programming ever since. Next to the SGRemotePropertyNode I've also been considering queering multiple properties in one shot, instead of one by one. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Monday, 20 December 2004 22:34, Martin Spott wrote: > Well, David Luff has proven that cross-platform-portability is not a > miracle, his "TaxiDraw" compiles at least on Windows and five different > Unices just with some small Makefile changes allthough he didn't > tell us how much effort he had to spend in order to achieve this > portability ;-) It's really easy when using a good, cross platform toolkit like wxWidgets. I've used wxWidgets for some cross platform network apps and so far I'm very, very impressed! I've tried other toolkits and as far as I'm concerned there's no other toolkit at the moment that is as feature filled and cross platform friendly as wxWidgets. 12 years of work has gone into wxWidgets (formerly wxWindows) and it really shows. The best thing about wxWidgets is it uses the native GUI controls of each OS so it looks totally native and you can't tell what platform the app it was written on. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Tuesday, 21 December 2004 12:10, Thomas Förster wrote:
> I'd go with option three. I see the FG core (the simulator itself) as an
> independent "demon". Multiple 'control' clients can connect and interact
> with the FG server ('GUI', Atlas Moving Map, Flight Tutor*, Flight
> logger, ...). We might need a locking mechanism to have only 1 client
> writing properties though.
It would be really nice to have all those features in a single controlling
client app with a single connection. One tab for aircraft selection, another
tab for a flight planner, one for instructor console, etc.
Having one app means you only need one connection without the risk of any
contention.
Of course getting several people to work on the same app with the same vision
can be tricky. :)
> That's a definite goal, to have a clean API to the simulator core, which is
> used by an internal as well as an external GUI.
I would love to see all the FG core stuff going that route - one network
capable API that everything can work through including FG itself.
As far as I can see FG looks like it's already half way there.
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Monday, 20 December 2004 21:04, Curtis L. Olson wrote: > That certainly sounds doable, although the particular details of how to > launch, and kill, and detect if the child process is running will > probably vary wildly from platform to platform. If one uses a socket connection it becomes very simple. One could find the running process quite easily by just entering the correct IP and port numbers into the client. (Obviously with a default setting like 127.0.0.1: for all the new XP users who just want to try FG out so that it works "out of the box".) This way it can be run on a single machine or across a network. FG can be started and shutdown either independently or by the client app. No mutex's, no OS API calls, no semaphores, no checking for lock files ... The only trick is some people may have local firewall software on their PeeCees which may interfere with network connections. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Am Montag 20 Dezember 2004 22:20 schrieb Jorge Van Hemelryck:
> ...
> 1- the Control app launches and communicates with FlightGear, the latter
> being for instance a child process (or fgrun could be extended to
> communicate with FlightGear in this way)
>
> 2- FlightGear is launched at the same time as the Control app
>
> 3- FlightGear and the Control app can be run independently
I'd go with option three. I see the FG core (the simulator itself) as an
independent "demon". Multiple 'control' clients can connect and interact
with the FG server ('GUI', Atlas Moving Map, Flight Tutor*, Flight
logger, ...). We might need a locking mechanism to have only 1 client writing
properties though.
* some future app that gives remarks on flight performance, i.e. "Give
attention to engine rpm", "More left rudder" (just an idea :-))
> ...
> What is already clear is that FlightGear should not depend on this
> Control app. It must be possible to run FlightGear from the command-line
> without anything else. That is why I would be in favor of option 3.
+1
> Here is what is already possible with what we presently have. The
> FlightGear telnet protocol allows an external program to get and set
> properties. This already allows for environment / position / time /
> radio / gps / view settings, to name a few.
>
> The current gui (menubar) can do more than that, and in the future it
> would probably a good thing to use the same API, in order for instance
> to be able to launch a nasal command from the Control app.
That's a definite goal, to have a clean API to the simulator core, which is
used by an internal as well as an external GUI.
> As we said before, the main problem would be to change aircraft (and
> therefore reinit FDM, 3D model, systems) without restarting FG. I'll try
> and have a look at the initialization code as soon as I find some time.
Great.
Thomas
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Mon, 20 Dec 2004 13:04:47 -0600 Curtis L. Olson wrote: > That certainly sounds doable, although the particular details of how to > launch, and kill, and detect if the child process is running will > probably vary wildly from platform to platform. The only OS where I could do it would be Linux (I have done some programming on Windows in the past, but not enough to be able to do that). I thought that the way to do this would be the same on UNIX-like systems, and that it would differ only on Windows... Here are the ways of launching the simulator and the "FlightGear Control" app I can think of: 1- the Control app launches and communicates with FlightGear, the latter being for instance a child process (or fgrun could be extended to communicate with FlightGear in this way) 2- FlightGear is launched at the same time as the Control app 3- FlightGear and the Control app can be run independently With option 1, there are issues such as how to ensure that when FlightGear exits, the Control app reverts to a launcher app. Does option 2 mean that they have to be launched at the same time ? Could we benefit from this ? What is already clear is that FlightGear should not depend on this Control app. It must be possible to run FlightGear from the command-line without anything else. That is why I would be in favor of option 3. Here is what is already possible with what we presently have. The FlightGear telnet protocol allows an external program to get and set properties. This already allows for environment / position / time / radio / gps / view settings, to name a few. The current gui (menubar) can do more than that, and in the future it would probably a good thing to use the same API, in order for instance to be able to launch a nasal command from the Control app. As we said before, the main problem would be to change aircraft (and therefore reinit FDM, 3D model, systems) without restarting FG. I'll try and have a look at the initialization code as soon as I find some time. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
I realize that. I just meant that the more the source code forks into different applications the harder it will be to keep it all working across platforms. Each person who is working on their own particular app. Will make sure that it works on their own platform. While if there is one "FlightGear" app. Then there is a joint effort, with each change in source, to get it to work across many platforms. -- Adam > From: Martin Spott <[EMAIL PROTECTED]> > Organization: home > Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > Newsgroups: list.flightgear-devel > Date: Mon, 20 Dec 2004 20:34:15 + (UTC) > To: <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45 > > Adam Dershowitz wrote: > >> But cross platform support gets more difficult. This is somewhat >> demonstrated by the issues that someone is having right now getting fgrun to >> compile and build. > > Well, David Luff has proven that cross-platform-portability is not a > miracle, his "TaxiDraw" compiles at least on Windows and five different > Unices just with some small Makefile changes allthough he didn't > tell us how much effort he had to spend in order to achieve this > portability ;-) > > Cheers, > Martin. > -- > Unix _IS_ user friendly - it's just selective about who its friends are ! > -- > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Adam Dershowitz wrote: > But cross platform support gets more difficult. This is somewhat > demonstrated by the issues that someone is having right now getting fgrun to > compile and build. Well, David Luff has proven that cross-platform-portability is not a miracle, his "TaxiDraw" compiles at least on Windows and five different Unices just with some small Makefile changes allthough he didn't tell us how much effort he had to spend in order to achieve this portability ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Paul Surgeon wrote: It still needs a bit of work though. One cannot change the aircraft or location at the moment through an external app. You can't change aircraft through the internal or external gui right now. You can change position just fine, as well as setup things like 7 mile final, on a 3 deg. glideslope, at 90 kts. I also noticed that connections have a direction associated (in/out). To have a bi-directional connection does one have to use two seperate connections? No, not with the "telnet" interface. Also is the hz parameter required? Isn't it event driven? Polling is evil! ;-) I've seen some event driven gui/socket code that was (of all things) written in MSVC. There are plenty of messes already in FG so that's one direction I'd really rather not go. The way I see it is we can have a GUI that the user launches that in turn loads FG in the background. Similar to fgrun but with a live connection like the flight instructor type setup. When the user is done configuring aircraft, weather, etc they press a "SYNC" or "FLY" button and the changes are sent to FG and FG is told to pop up (brought to the foreground). That certainly sounds doable, although the particular details of how to launch, and kill, and detect if the child process is running will probably vary wildly from platform to platform. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Monday, 20 December 2004 14:08, Curtis L. Olson wrote: > For what it's worth, I think that some sort of minimal built in gui for > FG is still a good idea. FG already provides a lot of support for > developing an external gui It still needs a bit of work though. One cannot change the aircraft or location at the moment through an external app. I also noticed that connections have a direction associated (in/out). To have a bi-directional connection does one have to use two seperate connections? Also is the hz parameter required? Isn't it event driven? Polling is evil! ;-) > The only issue is that for single PC, home users who aren't immensely > computer savey, starting up multiple apps concurrently can be a bit > tricky ... especially in a multiplatform / portable context. The way I see it is we can have a GUI that the user launches that in turn loads FG in the background. Similar to fgrun but with a live connection like the flight instructor type setup. When the user is done configuring aircraft, weather, etc they press a "SYNC" or "FLY" button and the changes are sent to FG and FG is told to pop up (brought to the foreground). Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Thomas Förster wrote: Is there documentation on this (writing external UI's) somewhere? Thomas, There's no specific documentation, but what I did was leverage the "telnet" interface which gives you a convenient way to interact with the FG property system. It's relatively "low bandwith" but that's generally fine for a gui. The "telnet" interface also provides some higher level "commands" which are convenient for remotely controlling the app. It's an approach that works quite well (at least on linux.) I have control over the machine so I can set all the various apps to startup the way I like and can have complete control. I'd shudder to try to roll multiple concurrent apps into a user release though because it's a fragile house of cards. I can get it setup on my own system, but any little change or difference can bring the whole thing crashing down, and for users that don't understand how it all goes together, they may not be able to easily modify the scripts to make it all work. But if we can work through the management/distribution/platform/usability issues, I think it would be a great thing to have. You can do so much more, so much more easily with a real gui tool kit than you can do in pui. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
> From: "Curtis L. Olson" <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions <[EMAIL PROTECTED]> > Date: Mon, 20 Dec 2004 06:08:51 -0600 > To: FlightGear developers discussions <[EMAIL PROTECTED]> > Subject: Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45 > > Jon Stockill wrote: > >> Thomas Förster wrote: >> >>> I also thought about this as an option for a GUI. The main advantage >>> would be that this approach ensures there's no GUI code in FG and >>> there is a well designed API/Protocol to it. Writing alternative >>> GUI's should be easy using that API/Protocol. Having the GUI >>> seperated also makes it easy to distribute the apps across machines, >>> i.e. having a simulator with an instructors workplace (changing >>> weather, fail engines...) >> >> >> With the added advantage of not bloating the simulator - gets my vote. >> > > For what it's worth, I think that some sort of minimal built in gui for > FG is still a good idea. FG already provides a lot of support for > developing an external gui (i.e. for an operator/instructor station.) > I have done exactly this for the ATC flight sim single engine trainer > and it works quite well. > > The only issue is that for single PC, home users who aren't immensely > computer savey, starting up multiple apps concurrently can be a bit > tricky ... especially in a multiplatform / portable context. > > Curt. > > -- > Curtis Olsonhttp://www.flightgear.org/~curt > HumanFIRST Program http://www.humanfirst.umn.edu/ > FlightGear Project http://www.flightgear.org > Unique text:2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d But cross platform support gets more difficult. This is somewhat demonstrated by the issues that someone is having right now getting fgrun to compile and build. By keeping a single application there is a bunch of support, and a bunch of drive to keep the code base working across platforms. If the code splits into a bunch of different applications then people are needed to build/test/support each separate app. on each platform. In theory that should not be that hard, but in reality, I believe, no one has yet built fgrun for the Mac... --Adam ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Am Montag 20 Dezember 2004 13:08 schrieb Curtis L. Olson: > Jon Stockill wrote: > > Thomas Förster wrote: > ... > For what it's worth, I think that some sort of minimal built in gui for > FG is still a good idea. FG already provides a lot of support for > developing an external gui (i.e. for an operator/instructor station.) > I have done exactly this for the ATC flight sim single engine trainer > and it works quite well. Is there documentation on this (writing external UI's) somewhere? Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
> The only issue is that for single PC, home users who aren't immensely > computer savey, starting up multiple apps concurrently can be a bit > tricky ... especially in a multiplatform / portable context. Wrap that in a script/launcher app/... KDE starts some 10-15 apps/demons on initialization, the whole Gnome desktop is based on networked components (CORBA). Yet both aren't normally counted as apps that aren't friendly to the end user. Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Curtis L. Olson wrote: Jon Stockill wrote: Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well. Agreed - the internal GUI we have at the moment, while not the prettiest available certainly gets the job done, and can be configured without having to resort to coding - it's perfectly adequate for the job. What I was against was multiple GUIs util different toolkits, as that would significantly increase the bloat, and make packaging flightgear an awful lot more complicated. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Jon Stockill wrote: Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. For what it's worth, I think that some sort of minimal built in gui for FG is still a good idea. FG already provides a lot of support for developing an external gui (i.e. for an operator/instructor station.) I have done exactly this for the ATC flight sim single engine trainer and it works quite well. The only issue is that for single PC, home users who aren't immensely computer savey, starting up multiple apps concurrently can be a bit tricky ... especially in a multiplatform / portable context. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Thomas Förster wrote: I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) With the added advantage of not bloating the simulator - gets my vote. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
> Here are a few ideas: > > - we could extend fgrun (to add such features as flight planning, AI > objects editing), > > - we could create another app, which would be meant to communicate with > FlightGear in realtime (probably via the telnet interface), something > more elaborate than the http interface, in the same way that fgrun does > for command-line options I also thought about this as an option for a GUI. The main advantage would be that this approach ensures there's no GUI code in FG and there is a well designed API/Protocol to it. Writing alternative GUI's should be easy using that API/Protocol. Having the GUI seperated also makes it easy to distribute the apps across machines, i.e. having a simulator with an instructors workplace (changing weather, fail engines...) > - in any case, it would be best to make sure that FG is able to change > aircraft (FDM, 3D model, systems) on the fly, because that is probably > the only start-up-time setting that can't be changed so far once > FlightGear is running. That would be a great improvement. Having spend most of the weekend trying to install CVS versions of all the FG dependencies I only spent a few hours designing a new order/labeling in the menu (using QT Designer just because it's a graphical UI Designer). From that I think easy improvements can be made just by renaming things. For example the difference between 'Adjust view distance' and 'Adjust LOD ranges' is not obvious. It's only after you click one you notice it was the wrong :-) Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Erik Hofman wrote: > I think most of the other binary distributions include fgrun. At least > IRIX and Solaris do. ^^^ Really ? I think I didn't add it to the package because 'fgrun' doesn't have this priority in my eyes but I can add it the next time, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Saturday, 18 December 2004 11:43, Jorge Van Hemelryck wrote: > - we could create another app, which would be meant to communicate with > FlightGear in realtime (probably via the telnet interface), something > more elaborate than the http interface, in the same way that fgrun does > for command-line options That's a great idea. 1. It means that we don't have to mess with FG code which is a turning out to be a real headache especially when trying to get some input from the core developers who are probably very busy with other more important things. This means we can develop outside of FG very quickly without having to worry about keeping everyone else happy. If they don't like it they don't have to use it. 2. It's dynamic (none of this static .fgfsrc file stuff that FG only reads when starting) The only thing now is to get one of the core developers to update the interface for us so that we can load aircraft, push new flightplans to GPS units, etc. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Jorge Van Hemelryck wrote: Have you had a look at fgrun ? It works in exactly the way you've just described. http://sourceforge.net/projects/fgrun/ Source only so far (except for windows), but maybe it's time to make some binary packages for other systems as well. I believe the Windows FlightGear package actually includes fgrun. The toolkit used is fltk (http://fltk.org/), available for at least Windows, Linux and MacOS X. Other systems might be supported, as fltk is OpenGL-based although I haven't paid much attention to reports of it working on these other systems (*BSD, IRIX, Solaris, etc.). I think most of the other binary distributions include fgrun. At least IRIX and Solaris do. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Fri, 17 Dec 2004 22:43:53 +0100 Richard Andrews wrote: > This is the same sort of idea I had been toying with. As a newbie to fg I > felt > that one tool that would be very handy would be a form of Linux QT > FG-launcher. It would simply generate the appropriate config file from the > users selections (--aircraft etc) and then launch fg with the newly generated > config. This could make fgfs suddenly more approachable to new users. Have you had a look at fgrun ? It works in exactly the way you've just described. http://sourceforge.net/projects/fgrun/ Source only so far (except for windows), but maybe it's time to make some binary packages for other systems as well. I believe the Windows FlightGear package actually includes fgrun. The toolkit used is fltk (http://fltk.org/), available for at least Windows, Linux and MacOS X. Other systems might be supported, as fltk is OpenGL-based although I haven't paid much attention to reports of it working on these other systems (*BSD, IRIX, Solaris, etc.). I'm pretty sure that quite a few Linux / UNIX users would like to benefit from the fgrun interface. They might not be aware that it exists at all... Here are a few ideas: - we could extend fgrun (to add such features as flight planning, AI objects editing), - we could create another app, which would be meant to communicate with FlightGear in realtime (probably via the telnet interface), something more elaborate than the http interface, in the same way that fgrun does for command-line options - in any case, it would be best to make sure that FG is able to change aircraft (FDM, 3D model, systems) on the fly, because that is probably the only start-up-time setting that can't be changed so far once FlightGear is running. -- Jorge Van Hemelryck ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
