Dirk Reiners wrote: > Hi Allen, > > Allen Bierbaum wrote: >> With the ability to get the fcd xml data, it is possible to add >> additional metadata to the fcd file and use it without extending the >> current APIs. (just read and parse the XML data at run-time to get at >> the information). I have started using this in one application and just >> committed a test to show everyone some of the things I am thinking of >> adding. >> >> Take a look at: http://opensg.vrsource.org/trac/changeset/230 >> >> This adds min_value and max_value for Real fields and a list of >> potential_value enums for GLenum fields. >> >> Any comments? > > I like the basic idea. I think the interface (having to parse the XML > string) is powerful but pretty complicated, so I don't know if I like > that very much.
Any ideas how to fix that? I guess we could extend the C++ interface for type description to have a string-to-string attribute map and fill the map with all of these attributes. Would that make it more useful? > > For the min/max values there is not much to say, those work well. > > The problems I see with the enums is how to map them to actual values, > as OpenGL does not have that ability. The same is true for other kinds > of enums. It might make sense to do > > potential_values="GL_AMBIENT=0x8a20,GL_DIFFUSE=0x8a21" > > instead, which would also allow an inverse mapping. This mapping needs > to be correct and correspond to the one in the code, but we might be > able to create a unit test for that using some preprocessor magic and > fcdProcess. Agreed. As you may have guessed I am using this in Python code which allows me to do the lookups by value. What we could do to get the reverse mapping is to write a little script that can be given an fcd file and set of header files (GL.h, etc) and it will look for all the potential_value fields of enums and make sure they all have reverse mappings and the mappings are correct. If you are interested in this I may be able to write a script like this over the weekend. > This info could also be used to create a new interface for enums that is > string-based, and maybe also to create the code for defining the enum > automatically in the base class (not for external constants like OpenGL, > but maybe for internal ones). I have been toying with the idea of an > Enum Field over the years, but never got to a good implementation > option. This might be a way to get there. Sounds interesting. I like how the C++ code currently works where you can use extended capabilities without OpenSG having to change or know about them. But I could see the set by string being useful for some people. -Allen > Yours > > Dirk > > ------------------------------------------------------------------------- > 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 > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > ------------------------------------------------------------------------- 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 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
