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
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
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
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
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
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,
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
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
22 matches
Mail list logo
