Re: [Opengc-devel] Theoretical question re: customization

[Damion S. <be...@cs...>]

Hi,

I've got a few suggestions. As I mentioned in a few earlier emails, I'm 
in the process of rewriting and relicensing the "core" part of OpenGC. 
Although the changes to existing gauges will be relatively minor, the 
affect of the "philosophy" of OpenGC will be larger. Right now, OpenGC 
is both a toolkit and an application. While nice from an organization 
standpoint, this causes the sorts of problems that you're running into; 
i.e., the difficulty of maintaining different private and public 
versions of code.

The rewrite that I'm working on is primarily focused on shifting OpenGC 
more completely into the toolkit realm. Under the new philosophy, 
OpenGC is a bunch of components that you can use to write an 
application, but not an application itself. Therefore, main.cpp and the 
AppObject class will become examples in how to _use_ the forthcoming 
OpenGC libraries, and not form the basis of a complete application. As 
far as end users are concerned, the executable that is obtained from 
compiling this example will still be "OpenGC", but as far as developers 
are concerned, OpenGC is a set of libraries you can link against to add 
cockpit data acquisition and rendering to your application.

A side effect of this is that I will be a little more concerned with 
making the various classes completely portable. Right now, for example, 
the RenderObject class (the base for both gauges and components) 
requires a pointer to an AppObject. This of course locks you into the 
application framework, and hence FLTK, and therefore complicates the 
lives of developers who might want to use something other than FLTK 
(e.g. embedding OpenGC into an existing applications).

With the new "portable" philosophy, any code you'd like to contribute 
or maintain internally should not interfere with any other code in the 
repository. The data source base object needs considerable work on my 
part; in particular, it needs an easy way to identify which variables 
in the base class a particular sim supports, and whether or not those 
are read/write/both. If this facility existed, it seems like it would 
address your problem (the need to have variables not present in 
OpenGC). What I'd like is for the base DataSource class to become 
arbitrarily complex; i.e., add whatever you want. With proper 
initialization, gauges that require the specialized data would simply 
not function (by always receiving the default value) with a data source 
that did not implement a method for retrieving this data from the sim.

Does this sound like it would meet your needs? Perhaps there could even 
be some sort of global warning that would pop up that says "The gauges 
you are trying to use require data not supported by the data source you 
have selected".

Your comments would be appreciated. I'm trying to move to a design 
model more along the lines of VTK and ITK, two toolkits that have been 
extremely successful ( http://www.vtk.org and http://www.itk.org 
respectively). One of the reasons they work so well is that they are 
extremely compartmentalized and don't force design decisions on their 
users; I'm a bit concerned that the current OpenGC makes a number of 
assumptions that force users into a particular application model. 
Hopefully the "new" OpenGC will avoid this...

Cheers,

-Damion-

On Tuesday, October 28, 2003, at 07:02 PM, Pollack,Matthew E. wrote:

> We at MITRE have been using OpenGC for a few months now, and have
> recently run into an issue that we are not sure how to tackle.  We have
> a custom, internally developed flight simulator that has both outputs
> that MSFS, FG and X-plane do not have and requires inputs different 
> from
> the aforementioned flight sims.  Up until now, we have been adding
> variables to the ogcDataSource class to support our needs.  However,
> this precludes us from making a smooth transition to newly released
> versions of OpenGC.  Does anyone have any ideas as to how we might be
> able to both support our needs, while, at the same time not breaking 
> any
> backward compatibility with the reference implementations of OpenGC?
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Opengc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengc-devel
>
>

---------
Damion Shelton
Carnegie Mellon University, Robotics Institute
A408-o Newell Simon Hall
412.268.3866 (office)
412.818.8829 (cell)
412.268.6436 (fax)
http://www.cs.cmu.edu/~beowulf
---------
I wish I would have a real tragic love affair and get so bummed out 
that I'd just quit my job and become a bum for a few years, because I 
was thinking about doing that anyway.