I'm trying to build 3 MFDs that each have several pages --one has 7 or more ( 
the aircraft is still in development)

I'm not sure what the simplest organization is.  Nested layers seems complex as 
there as 6 instruments plus text and lables on several pages.

I was thinking I would organize each page as a panel. so I tried giving the 
different panels the same name and looked for an array in the property tree 
that I might work with --didn't find anything. Is there a way to turn panels on 
and off? 

maybe I could add a switch statement somewhere in the source code that reads a 
property? 

Steve 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathias Fröhlich
Sent: Thursday, July 27, 2006 10:16 AM
To: FlightGear developers discussions
Subject: Re: [Flightgear-devel] HUD: raw gl-commands vs. plib/osg wrappers


Melchior,

On Thursday 27 July 2006 09:58, Melchior FRANZ wrote:
> * Mathias Fröhlich -- Wednesday 26 July 2006 22:49:
> > Because it is not a limitation but rather a gain. A *well* *done* and
> > *well* *supported* scenegraph will help you some much more than you
> > probably can imagine now.
>
> You completely miss the point: we are using ssg! There was no
> decision made to switch to osg. So, if we switch to ssg wrappers
> first, we lose capabilities, that we may or may not get back later.
>
> I don't accept that and object.
>
> > In fact, a proper design - like a well done scenegraph provides
>
> You miss the point. We are using ssg!
>
> > So why should we limit ourselves in the long term with ssg?
>
> Fact is: we are using ssg. We may or may not switch to osg later.
> There has *no* decision been made, so we can't rip out stuff now
> that osg may provide later. The way to go is:
>
>  - formal decision to switch to osg (or at least to start working on it)
>  - generate osg branch in cvs
>  - parallel development
>
> In the osg branch you can do with the HUD what you like. But not
> in the current, *SSG* branch.

I believe that you miss the point.
The point is that we can, without loosing features, with a sensible design, 
prepare getting rid of ssg. As allmost allways, building sensible structures 
is a win even if no switch will happen.
Just blocking that is not a good idea.

... did you ever look at the sceens of csp.sf.net?

     Greetings

          Mathias

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to