Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-21 Thread Thomas Förster
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

2004-12-21 Thread Paul Surgeon
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

2004-12-21 Thread Paul Surgeon
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

2004-12-21 Thread Paul Surgeon
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

2004-12-21 Thread Erik Hofman
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

2004-12-20 Thread Thomas Förster
 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

2004-12-20 Thread Jon Stockill
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

2004-12-20 Thread Curtis L. Olson
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

2004-12-20 Thread Jon Stockill
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

2004-12-20 Thread Thomas Förster
 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

2004-12-20 Thread Thomas Förster
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

2004-12-20 Thread Adam Dershowitz


 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

2004-12-20 Thread Curtis L. Olson
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

2004-12-20 Thread Paul Surgeon
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

2004-12-20 Thread Curtis L. Olson
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

2004-12-20 Thread Martin Spott
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

2004-12-20 Thread Adam Dershowitz
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

2004-12-20 Thread Jorge Van Hemelryck
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

2004-12-18 Thread Jorge Van Hemelryck
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


Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45

2004-12-18 Thread Erik Hofman
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

2004-12-18 Thread Paul Surgeon
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

2004-12-18 Thread Martin Spott
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