> > Hi Allen, > > Allen Bierbaum wrote: >> I would like to suggest changing HDI to "HowTo". I was seriously >> confused when I saw that entry in the menu. I though it was some new >> rendering technique or cable connection standard. :) >> > Good point. Done. ;) >> There are a couple of sections I see missing in the toc. >> >> - Mailing lists (it is under "Community", but it took a bit to find >> that) >> - Development discussions: I think there should be a section related to >> coding and development. Maybe a main page to index ongoing development >> discussions (ex: ptr ideas, documentation plans) and some other pages >> related to development and extension of the project (ex: coding >> standard, fcdEdit usage, etc) >> - BugReports and FeatureRequests: Make it so people don't have to see >> and understand the top bar menu. >> > Feel free to add whatever you think is necessary. That's true for > everybody. If I disagree with anything I'll let you know.
Okay. I would also like to play with the idea of using section headings that are in bold or something (like Adium's website). I think it would make the structure more apparent. >> Agreed. I would also like to throw out the idea of using autolinking >> with the OpenSG libraries. If we were to use autolinking to pull in the >> libraries and continue on the path we have been for eliminating the need >> to pass defines to the compiler, then the basic setup for compiling an >> OpenSG application could almost be simplified down to creating a >> standard console application and adding the OpenSG header path to the >> include search path. >> > I don't generally like the Microsoft special thingies... Do those work > with unspecified paths? I'd like to avoid hardcoding anything if possible. It doesn't have any hardcoding. All it really does is automatically add a library to your link line whenever that object code is linked into an application. It is used successfully on Boost and we have started using in with VR Juggler and our other projects. In my opinion it has made building on windows quite a bit easier. >> This is a little bit of an aside, but I think the core list should be >> eliminated or simply made public as an opensg-dev list. >> > It's public, so there's nothing secret about it. We had a dev list in > the past, but everybody just kept copying both users and dev, and dev > became useless. Core is IMHO a better name, as it suggests being or > people deep inside the guts of it. Okay. I thought people couldn't subscribe to it. This makes sense then, it is just the development list. >> Agreed. Moving from "test" examples to a separate directory of examples >> would be a huge help. > I don't like the separate directory idea very much, in order to keep > everything close to the code I'd rather have them in the source tree and > have an automated way to collect them. The big argument I see for having an "examples" directory is that the code is then not hidden in the source tree when a new user downloads and uses OpenSG. Instead they can see "here is a directory of examples that I can look at". That is one thing that is very impressive about OpenSceneGraph when you first download it, there are a ton of examples sitting in a directory for you to use. OpenSG has just as many "test" examples, but people don't see them. I know it may be a little annoying to existing developers, but I think a separate example directory would help out users and help with promoting OpenSG. Anyone care to agree or disagree with me? :) >> I have said it before, but it bears repeating. >> Every time a new feature or even minor capability is added there should >> be an example that is either extended to show the capability or a new >> example created to show off the feature. >> > It sounds like a good idea, that we should try to follow. But if anybody > else has an example program they would like to contribute: send it my way! >> This simple change could dramatically help marketing. By making the >> examples part of the build process and thus get them into the nightly >> build we get a package that is always ready to go to show off OpenSG. >> Then when a new feature is added we wait a day and announce it on >> OpenGL.org (and other sites) with screenshots and a like to download the >> OpenSG nightly build to see the example in action. Pretty developer >> friendly marketing IMHO. :) >> > We just need to get it to that point, but generally: yes! ;) >> How can we help out with the site and the wiki? Should we work to get >> some of the points and arguments in these discussions documented on the >> wiki for further refinement? >> > Please do. In general: the Wiki right now is free for all changes. We'll > nail it down later before it becomes the official site, but for now I'm > totally open to new ideas and things that are missing. One hint: the > menu is on page TOC (see Title Index). How do you want the "development" discussion area structured? Just a single page with links spawning off or something more structured? -Allen > > Yours > > Dirk > > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Opensg-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/opensg-users > > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
