Re: [Flightgear-devel] [Re] Buildings?????
Am Donnerstag 24 November 2005 14:38 schrieb Steve Hosgood: On Thu, 2005-11-24 at 12:20, Ralf Gerlich wrote: Hi, Buchanan, Stuart schrieb: Hi Steve, Apologies if I've misunderstood your answer, but I think we can already do this by setting the FG_SCENERY environmental variable appropriately. This is actually the way I'm using the Lake Constance scenery and it's the way proposed on the Lake Constance Scenery Download site. It works. OK, so what was the original poster bothered about again? Sounds like it's all working as expected. The complaint was not about being able to have customized scenery. The complaint was that there is no way of customized scenery to become part of the standard scenery. That way everyone could share the joy of nicely modelled local sceneries, not just the original creator. I'm sure a lot of people here are willing to contribute their scenery enhancements (copyrights permitting), but currently just can't do it. This was the reason to create a Shapefile (being a standard format in the GIS communities) Scenery DB in the first place. As long as FGSD has no support for these (or similar) formats, there is no way to merge different contributions. That's why Martin noted that FGSD probably MAY be a dead end regarding terrain modelling. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Am Dienstag 22 November 2005 17:06 schrieb AJ MacLeod: On Tuesday 22 November 2005 15:41, Erik Hofman wrote: The skylight model we are using is also based on physical properties and isn't far off from the model you describe. That model however doesn't allow for some of the cloud colorings features we are doing. Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg In fact our model still has a lot of potential left. I wouldn't want to trade it for another approach. I don't know anything about the theory of it all, but I do know that the sky in FG looks truly amazing at dawn and dusk in particular (colours, moon phases, star positions etc) - and I think we are _really_ underselling FG by not having a few screenshots illustrating that on the website. I'm sure others can come up with much nicer ones than I have... they're all going to offend the darkness police whatever :-) I think Melchior knows how to swap textures/materials at runtime. Probably it's time for fake lighted livery... In a Berlin building in Jon's Scenery Objects DB (Park Inn Hotel), I used a light emitting material together with a night texture (basically to darken the shadow areas) to fake an illuminated facade. Maybe this technique can also be applied to the stabilizer to light the company logo. I'm sure this would improve your scene enough to pass Curt's artistic judgement. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Review (was: Which aircraft to include in v0.9.9?)
Am Samstag 12 November 2005 02:05 schrieb George Patterson: On Fri, 2005-11-11 at 16:13 +0100, Thomas Förster wrote: A slightly outdated version of FlightGear is installed for Suse via Yast and via Apt for Debian. For the newest release you have to compile the source code yourself [1]. For Mandrake 10.2, Fedora Core 3 and the newest version 5.10 of Ubuntu packets exist for the current release 0.9.8 of FlightGear. The packets may be found here [2]. Last sentence of this paragraph should be The packages may be found here [2]. Sure. I was quite brain dead after having spent a whole afternoon on this. Must have slipped through the proof reading. Thanks. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Review (was: Which aircraft to include in v0.9.9?)
If someone needs translation into another language, you might try to translate the web page using google translation. http:// www.google.com/language_tools?hl=en The english language version is here: http://translate.google.com/translate?u=http%3A%2F%2Fwww.linux- user.de%2Fausgabe%2F2005%2F11%2F070-flightgear%2Flangpair=de% 7Cenhl=ensafe=offie=UTF-8oe=UTF-8prev=%2Flanguage_tools Google somehow only translated the first part into a very crude translation. So here is a better one (hand crafted ;-), other German speakers can probably correct me if I am wrong somewhere): Flying With FlightGear High Above -- UFO's over San Franscisco? With the free flight simulator FlightGear you leave this earth -- if needed in an UFO. Validate your free ticket here. Kristian Kißling, Jörg Luther --- README This article instructs you on the usage of the free flight simulator FlightGear and highlights its strong and weak points compared to its commercial competitors. Despite the so called low fare airlines, flying is an expensive hobby. This is even more true for piloting a plane yourself. A (hobby [sic!]) pilots training costs thousands of Euros, a visit in a professional full flight simulator comes at 200 to 300 Euro. No surprise, a lot of flight enthusiasts turn their PC into a cockpit: But even for flight sims for your own living room you have to spend 20 to 30 Euro -- extensions like additional models or detailed scenery excluded. This sums to a nice amount over time. On the other hand you can get the free flight simulator FlightGear platform independent and at no cost (Figure 1). Technically not in the same league like current commercial competitors, it is steadily developed further and with lots of features seems to be close to reality. FIGURE 1 ((1)) A Cessna passing the Golden Gate Bridge of San Francisco in the free flight simulator Flightgear. Check-in A slightly outdated version of FlightGear is installed for Suse via Yast and via Apt for Debian. For the newest release you have to compile the source code yourself [1]. For Mandrake 10.2, Fedora Core 3 and the newest version 5.10 of Ubuntu packets exist for the current release 0.9.8 of FlightGear. The packets may be found here [2]. To install FlightGear, you will need a 3D driver for your graphics card, since you will surely spare the bucking (TF not sure it's the right translation) without it. Install FlightGear via the respective packet manager. The console plays an important role: unlike other flight simulators you define parameters of the program before the start. With different options you determine for example the start position, the type of aircraft or the local time at the departure location. A typical start line is: fgfs --enable-fullscreen --aircraft=ufo --airport-id=KJFK --start-date-lat=2005:09:09:12:00:00 --enable-auto-coordination Now have a look to the single options: --enable-fullscreen turns on the fullscreen mode, for --aircraft you choose the UFO, departure aerodrome is John-F.-Kennedy airport (JFK) near New York. --- UFO: One of the less realistic aircraft in FlightGear. The UFO is fast, never crashes and provides a handy way to explore the scenery. Every airport worldwide possesses an ICAO code, which you can query at this website [3]. ICAO: ICAO stands for International Civil Aviation Organisation, which assigns airport codes to international airports. Your first flight does not start at JFK though: FlightGear by default only starts in the vicinity of San Franscisco. Other regions of the world can be downloaded from the FlightGear Website [4]: How to install such addons you can read in the box Extending FlightGear. = Extending FlightGear The FlightGear world is divided into 10x10 degrees quadrants. In the basic version you only get one such tile around Los Angeles, the rest of the world consists of water. With the right extension files [4], you get scenery for the rest of the world too. FIGURE 2 ((2)) If you like to fly to a new airport or region, first you must download and install the right scenery tiles. The download of so called scenery tiles causes tremendous download volumes: A single tile comes at around 80MB; flightgear.org provides the whole world scenery on 3 DVD for purchase. We have put the Middle European region onto the attached CD. The region consists of the four tiles from 0°E 50°N (e000n50.tgz) to 10°E 40°N (e010n40.tgz). Not only Germany but also Benelux, Denmark, the south of Scandinavia, large parts of France and Italy as well as the Balcan area come into your reach. To install the scenery, copy the archives from the CD depending on your distribution into the Scenery or Scenery/Terrain subdirectories and unpack with the command tar -xvzf e0*. In a similar manner proceed with other downloaded FlightGear scenery
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Am Dienstag 28 Juni 2005 18:42 schrieb Harald JOHNSEN: Martin Spott wrote: Frederic Bouvier wrote: Quoting Martin Spott : Look by yourself : http://terraserver.microsoft.com/image.aspx?T=4S=12Z=10X=706Y=5191W= 3 Oh, nice I think we urgently need a way to inject user-submitted landcover details into the process of scenery generation Curt, do you see a chance to accept geo-referenced shapefiles from users ? Martin. Since we are talking about scenary generation... Has no one wrote a converter from Taxidraw output to .btg ? Am I the only one frustrated because I can not (simply) edit a few airports and use the result imedialty ? From the terragear source I find it quite easy to do that, so if nothing exists I will write the converter. Mind that also the surrounding scenery tile .btg has to be edited, because it has to contain a hole exactly fitting the airport... Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting an airport fixed
Am Montag 20 Juni 2005 10:51 schrieb Martin Spott: Gerard Robin wrote: Le dimanche 19 juin 2005 à 22:10 +0200, Gerard Robin a écrit : I have the same request LFPO is wrong: -- take off point beside the runway Oh yes i have tried with taxidraw, it seem only operate on the taxiway, not the runway. I could not modify the runway start point There is no separate runway start point, it is _always_ automagically placed at the beginning of the runway. The effect you probably see is sitting at the end of a grass runway that is being listed _before_ the expected asphalt runway. To edit runways please click Edit - Unlock Runways, to change the list order of an airfield simply employ your favourite text editor. If you like to change the order or simply understand the structure of the airport file, please have a look here: Please not that changing runways is strongly discouraged, because they are mostly automatically derived from the DAFIF data. Usually the runway layout is not way off. Just giving the right runway on the commandline on startup should suffice. Eventually the most realistic option is to startup on the apron (data for that should already be in apt.dat.gz). But thats a different story... Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting an airport fixed
Am Sonntag 19 Juni 2005 22:36 schrieb Ampere K. Hardraade: On June 19, 2005 04:10 pm, Gerard Robin wrote: I have the same request LFPO is wrong: -- take off point beside the runway Thanks -- Gerard For me, it is the LFBO. 14L/32R is a dirt runway, and there is no taxiway connected to the ends of 14R/32L. =/ Taxiways are completely user submitted. A default taxiway layout is generated for airports without a database entry (taxiway parallel to runway, connected at both ends and the center to runway, apron in center). It maybe this applies only to asphalt and concrete runways. Best option is to take Taxidraw, layout a nice taxiway network (preferably the real one) an submit your changes to David Luff. It will be incorporated into the next scenery release. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] need help for convertion(importing) fron MS FS into Flightgear
Am Freitag 17 Juni 2005 16:13 schrieb yue xianf: Hi every one: any one can give me some hint about how to run the MS FS models under flightgear? I have searched for long time, It is said Wolfram's manual can help, http://home.t-online.de/home/Wolfram.Kuss/,this websit looks something else and also is Germany I don't understand. I very appreciate your help. Basically the site says that the original site does no longer exist. Apparently the hoster had changed their systems and informed all customers to move their sites. Yet their is no link pointing to the maybe moved site. Looks like this link may rest in peace... Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nighttime cloud lighting (was: today's 3d clouds commit)
IIRC NASA has a nice hires satellite photo of the earth at night. Maybe this could be used as a base texture. This could then be refined with the terragear city polys. Just an idea... Thomas Am Montag 16 Mai 2005 06:32 schrieb JD Fenech: Ampere K. Hardraade wrote: On May 15, 2005 10:21 am, Melchior FRANZ wrote: PS: TODO for 1.0: - perfect weather (almost) done - per-wheel gound reactions YASim: done; JSBSim: :-( UIUC: bah! - help system (a bit unsophisticated, but) done - a/c switchable at runtime hmm :-/ Let me add to this list. =) - The bottom of the clouds above a city at night should have a faint orange glow. The thicker the clouds, the brighter the glow should be. - Moonlight. - The global ambient should be blue. This should be most noticeable when at dawn and dust when the sun is not visible. As a general thought (speaking of the devil, I actually thought about the cloud lighting effect the other night as I was driving home, even though I can't really using FG due to superseded hardware), but not only the cloud thickness has an effect, but also the cloud base, and the size of the city which is lighting the clouds. Large cities definitely have an obvious effect, and medium towns (medium being population 7000 or more) have a smaller, but noticable effect, as well. Any smaller than this, and they tend not to have either the ground coverage with accompanying lighting, or the heavy industry which would have enough high-powered lighting to leave a footprint. For an obvious example of what I'm referring to, drive through a rural area which has small towns spotted around at a general distance of 5 to 10 miles from each other, with a large city or two at a range of about 20 to 30 miles out. Of course, this applies on a cloudy night...you'll see the difference between the small towns and the cities. JD ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another fgfs enabled rating!
Am Samstag 23 April 2005 19:26 schrieb Arnt Karlsen: ... ..how about re-doing your solo with --jgp-factory running, and make a movie? ;o) Well I could tape my digicam to the panel. Though I think a 30 sec starting roll isn't that amazing... ;-) Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another fgfs enabled rating!
Am Samstag 23 April 2005 19:58 schrieb Arnt Karlsen: Nevertheless we have way too much restrictions here in Germany, with new ones developed at an increasing rate after 9/11 (I'm currently filling a Request for a security check of my very own person :-( ) ..huh??? This is so you can walk to 'n from your plane and preflight etc it at your local and other airports? No, they just wanna make sure, that I'm not intending a spot landing in the next high rise (everybody would tell, wouldn't he?). It's just in a line with all the other big brother laws that came up lately. The only difference here in Germany is that I have to request that security check myself. Hopefully one day they'll spot the error in the GA pilot = terrorist assumption... :-( Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another fgfs enabled rating!
Am Freitag 22 April 2005 05:07 schrieb Dave Perry: I passed my instrument rating oral and practical (check ride) this afternoon. Five hours including the oral and ride. Congratulations Dave. Thanks to the entire FlightGear team for a great simulator with real world applicability! I really second this. I started flight school after FlightGear gave me the confidence that I could do it. The result is, that I had my first solo today (after just a bit more than 7 hours, think I'll need lots of alcohol to sleep tonight). Nothing spectacular, after three patterns my FI suddenly decided to leave the plane and I did 2 more patterns, while he was collecting flowers for the photo... :-) So also from Germany a big THANK YOU for the FlightGear team. Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problem with airport ENSB
Am Dienstag 05 April 2005 20:26 schrieb Timo Saarinen: Hi, Trying to start the Flightgear 0.9.8 with Svalbard airport ENSB (78 15 N - 15 30 E) the aircraft ends up to sea. I have correctly downloaded the tile and extracted it to correct location (Scenery/Terrain/e010n70). The Svalbard island can be seen east from the airplane. The other airports seem to work fine. Sounds like the airport itself is missing. Is there a file 'ENSB.btg.gz' in Scenery/Terrain/e010n70/e015n78? Are the file permissions correct? Cheers, Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Dashes in filenames
Am Montag 14 Mrz 2005 22:41 schrieb Martin Spott: Martin Spott wrote: I didn't hunt for debug output this morning but I'll do that tonight. My friend told me something like FlightGear is broken, it stops after selecting the A-10 - so I assume 'fgrun' works correctly, I was unable to reproduce after I reverted the filename change. I wasn't able to reprocude this effect with the A-10fl neither. Might there be an issue with this single A-10cl-set.xml file in the installer package which got lost (the issue) during renaming ? I'm aware that this souds a bit strange, but I would not tell this story if it actually didn't happen Problem with file permissions? Just a guess... Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] curve direction.
Am Donnerstag 20 Januar 2005 21:56 schrieb Curtis L. Olson: This is kind of off today's topic, but I have an unrelated question. Working in 2d space, given 3 points, I know how to compute a circle (center/radius) that passes through those three points. Now I need to compute the direction of curvature of the 3 points. In other words, moving from the 1st point through the second point to the 3rd point, is the direction of the circle clockwise (curving right) or counter clockwise (curving left.) Just take the cross product of the vectors 1-2 and 1-3 (any 2 vectors will work, if you ensure a consistent selection). This should give a vector of the form (0 0 z). The sign of z gives the rotation direction. Since this is a special case this simplifies to: dx1 = x2 - x1 dx2 = x3 - x1 dy1 = y2 - y1 dy2 = y3 - y1 z = dx1*dy2 - dx2*dy1 Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] aircraft required to start
Am Freitag 21 Januar 2005 08:59 schrieb Frederic Bouvier: Stewart Andreason a écrit : It seems this aircraft is required to start FlightGear. fgfs WARNING: ssgLoadAC: Failed to open '/usr/local/share/FlightGear/data/Aircraft/pa28-161/Models/pa28-161.ac' for reading Abort This plane is required by the AI/ATC module Which in turn has implications for the standard aircraft selection *hint* Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery
Am Montag 10 Januar 2005 17:26 schrieb Christian Mayer: ... I got an answer. They told me that the ministry decided that it'll be a security problem if people could the the coordinates of objects and places easily and quickly from the BayernViewer. The usual stupidity :-( As if it would make a difference, whether I can look up coordinates for free or have to buy a map, if I intend to fly a plane into something. So the alternative would be that I buy the map-data CD-ROM at ebay. They are not expensive (they are made for tramping and bike tours) - but too expensive for looking up just a few locations :( I've the DSAT5 at home. Coordinates are rather crude though. PS: Does anybody know an online map service where you can get the coordniates? For Berlin there is http://www.berliner-stadtplan.com 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
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
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
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
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
[Flightgear-devel] GUI Improvements was: Things to do to improve Flightgear
Am Donnerstag 16 Dezember 2004 18:45 schrieb Christian Mayer: ...[other GUIs besides PUI Well, I don't think that replacing PUI has a high priority. Thats probably right. I doesn't look that bad (but doesn't mirror the OS style). And it get's drawn by OpenGL with a low overhead. So we should improve the underlaying functionality first, bevore we consider exchanging PUI. I see it as an opportunity for me to step in, because GUI code should be fairly trivial, i.e. independent of domain knowledge. ...[multiple fg guis]... This sounds like unlimited resources where you can afford the luxurity to code a GNOME, as Qt, a Windows, a MacOS, a [...] interface... This was just the vision. The actual steps to get there might differ :-) But these toolkits provide more or less the same functionality, so translating the FG GUI to any one of them should be straight forward. I can help out with QT, maybe there are others who can do that for a GTK based solution, etc. A Qt only interface sounds good - but Qt isn't free for Windows (you'll only get an 30 day evaluation copy IIRC), so we can't use it :( That's the point why I opt for having multiple GUI implementations. I can't use the native Windows solution here on Linux, with QT it's the other way round. Most of the cross platform available toolkits are either ugly or hard to develop with. Going for an own GUI toolkit for plib is even more demanding. So giving the user a choice is probably the best way to go, i.e. using a QT-based one on Linux, a native Windows GUI on Windows, no GUI at all in a real simulator setting. Think I'll try to prototype something this weekend. Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Things to do to improve Flightgear
Am Mittwoch 15 Dezember 2004 14:48 schrieb Oliver C.: On Wednesday 15 December 2004 07:35, Paul Surgeon wrote: I hope we either drop PUI (plib's UI) or at least do a major upgrade to it. We use PUI in the menus at the moment and in my opinion the widgets look absolutely GHASTLY. What could we use instead of PUI? What gui library uses OpenGL? For integration with existing desktops it's possibly best to use their native libs. QT for example provides an OpenGL widget, so all of the gui (menu, dialogs) could be native QT Widgets. Also if the sim runs in the context of a GUI it will be easy to switch between them at startup, i.e. 'fgfs --gui-gnome' runs a GTK based GUI, whereas 'fgfs --gui-qt' runs a qt based one. Don't know about possible performance issues, though. :-( Thomas ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
