Dirk Reiners wrote: >[snip] > >Now to what we can do (and are doing) to remedy some of this. > >Website: Allen and I have been working on getting a better website >system up and running. Check out http://opensg.vrsource.org . It uses >Trac (trac.edgewall.org), which is a nice integration of Wiki, SVN, >Bugtracker and more, like a roadmap system based on tickets. I like it, >because it is pretty tightly integrated and easy to use. The whole >website is a Wiki now, and I would love to see people adding bits and >pieces to it, especially to the FAW, HDI, Gallery and Community parts. > > 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. :)
>The Gallery is a bit clunky still, I'll have to look for a better way of >doing that (might be my first Trac plugin... ;). I would also like to >get some feedback on the general structure. I looked at a lot of Open >Source projects and took the pieces that I think matter to us. Note that >currently the Trac svn is a little out of date, we'll move the SF svn >over there soon unless there are serious reasons not to. > > 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. >Build System: again, Allen and I (more Allen on this one) have been >working on getting an SCons-based build system up and running, that >cleans up a lot of the magic compiler options we used to need, and that >automatically finds installed libs etc. We still need to finish it and >try the minimal installation needed to make it work with VS, but I think >we have a good chance to make it work. What would be perfect if somebody >had some experience in setting up a VS Wizard for new projects, which >would make it very simple to help people use OpenSG projects. > 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. >If >possible it should be for VS2003 and VS2005, as both of those are still >heavily used. A quick google found some info about it, but they seem to >be very different from each other. > >One thing I do know I want for 2 is using precompiled headers. >Especially with using STL, some boost and our own template magic, header >preprocessing is a big chunk of compile time. Currently the bison/flex >files are just included in the svn, which alleviates the need for having >flex/bison, unless you change the .yy or .ll files. Given that the >installation comes through python too, there shouldn't be a need for >cygwin any more. There is still quite a bit of work to make the build >system complete, but IMHO SCons gives us a better environment in general >for making it work quickly. > >Related to the build system is the library structure, which is the main >reason why we have to be pretty careful about including optional things, >as right now we have very few libs that depend on a lot of things. So if >one of them is missing, the lib won't load and the system won't work. 2 >will move to a more fine-grained system, which will also help with link >times. There are still a bunch of questions with that, I've posted >another mail on the core list about that. > > 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. >Complex code: one of the main goals for 2 (there is that roadmap thing >again ;) was to simplify the code, both for users and for >extenders/developers. Part of that is getting rid of begin/endEdit >(that's done), and also simplifying a lot of the internal code (getting >rid of special pointers and a lot of the templates is some of that). I >don't see a way to make it as simple as trivial C++ lib, especially to >keep clustering working we do need capabilities from our data structures >that raw C++ doesn't give us (so fcdEdit resp. fcdProcess will stay. We >should probably move it over to python though, to get rid of needing >perl in the system. Sorry, Gerrit). There are probably still things that >are considered too complicated, and I'd be interested in hearing about >them. > > >Examples/Demos: That's IMHO one of our biggest weakneses. We don't have >cool demos, and the dists have very few real examples. We have the >SceneViewer, but it's pretty useless without QT (and it's written >against QT3 anyway). It would be good to have something that can beused >as a framework of sorts for demos, which makes it easy for people to add >a new code snippet that demonstrates a cool feature, and that people can >use to base their own programs on (not unlike Performer's perfly). It >would need to use a free GUI toolkit that is portable (Fox? wxWidgets?). >We would also need some demo data (maybe we can pinch some from OSG? ;), >and a little bit of animation to make it look interesting. > >Documentation: There are many widely varying opinions on this, me >thinks. Everybody wants more documentation, but I'm unsure what people >really need. Well, except the 'here's how to do what you want to do' >document. ;) Personally I think a well-designed system shouldn't need a >lot of documentation, the names of functions and parameters should stand >for themselves, but maybe that's just me. > >I agree that we need more examples, and I would love to get >contributions on this one. I think we need to shift the tests and >tutorials down a bit, and turn them into unit tests and examples. The >unit tests should be very simple and really just test a very specific >feature for correct operation, without interaction or anything. The >examples should be better than tests in the sense that they demonstrate >a feature and show how it's used, but without the lengthy explanations >of the tutorials, which take a lot of time to write. It would be nice if >we could make the examples short enough to fit them into the >documentation, to be ready for cut-n-paste. Maybe by using a common >skeleton, similar to the tutorials and moving all the actual work into a >single function that is doable. > > Agreed. Moving from "test" examples to a separate directory of examples would be a huge help. 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. 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. :) >[snip] > >Animation/Higher-Level Systems/Manipulators: As said in a previous mail, >I absolutely see the need, and I would like to add hooks to make it easy >to use, but I don't have the bandwidth to lead the design/development. > >I don't have strong ownership feelings about any of the stuff mentioned >above (there is some stuff that I haven't mentioned that I do ;). So if >anybody thinks that he or she can put some effort into any of them, that >would be very much appreciated. > > 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? -Allen >Comments (hopefully lots ;)? > > 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
