Hi, On Thu, 2010-01-14 at 14:35 -0600, David Kabala wrote: > > > On Thu, Jan 14, 2010 at 4:45 AM, Gerrit Voß <vo...@vossg.org> wrote: > > > > > > These libraries are for OpenSG 1.8. However, we are in the > process of > > > porting them to OpenSG 2, and would like to open up a > discussion with > > > the OpenSG dev team for possible inclusion in future > releases of OpenSG. > > > > sure, since the code itself is LGPL from what I've seen, it > should not > > be a problem. The simplest form of inclusion would probably > to turn the > > parts into Contrib libraries (mainly because they add new > 3rd party > > dependencies), although a few things might better become > regular > > components. How modularized are the above parts, can they > exist as more > > or less independent libraries or do they have dependencies > on each other? > > > I started looking at it, in particular the 2.x work which > seems to be > available in the sourceforge git repository. From glancing > over it > (so far) we should definitely start the discussion as soon as > possible. > > Yes, the toolbox-migration branch on the git repo: > git://opensgtoolbox.git.sourceforge.net/gitroot/opensgtoolbox/opensgtoolbox > > This is just being used for development purposes for porting and is > very much under development. > > > > Some of the core changes I see problematic (e.g. virtual > function in > fields). > > This, was just modified to allow for easier porting, as there were > virtual functions similar to these in fields in 1.8. These were > placed in for easier porting of the Animation library, and the XML > reader/writer in FileIO. >
ok. > > Other things I do have to understand better, e.g. promoting > something > like the event concept to core inclusion (in the main tree, > not inside > contrib) is something we have tried to avoid as we did not > want to > enforce a particular application model. But I don't know > enough about > your approach to judge all the implications. E.g. what would > have to > change for all containers so that this model works > consistently and > not only for the parts from the toolbox or how would things > work > without using your mainloop, e.g. with the simple or complex > managers > and their app models that are already there. > > I realize that what I am doing with the event system is not documented > on a high-level. So, I will try to write up some on what it is the > code is doing. not that urgent, something running is equally helpful ;) > > I feel that moving the event production to core would be helpful, and > could be done in a way that wouldn't force a specific application > model. However, it sounds like you would like to move the > WindowEventProducers out of the core, and into something like a > contrib lib. In my rush to start the porting process I just put them > in the core, but understand that they should probably be moved to a > contrib library. > > In summary, I think it would be useful to put the base code of the > Event and EventProduction in the core, and moving out the specific > native WindowEventProducers to a Contrib library. > as I said currently I have no fixed opinion where to put things, the route basics are also inside the core as is a generic frame handler for the anim stuff. As long as we don't enforce one particular app model I'm fine. I still would tend to start with everything outside the core and than gradually move it over. > > We also have to in general, independent of this concrete set > of libs, > think a little bit about naming for things in contrib as I > guess some of > the names will clash. > > Ok, jumping into the technical discussion, if possible (and > hopefully > without to much work on your side) I would like to propose a > slightly > different inclusion process from what you started in the sf > git repo. > Ideally we could use this as the general blue print, and > derive some > documentation of the process from it. > > The general process I would like to use, given that the > current > cmake system makes it possible to include externally kept libs > into the OpenSG build quite easily (e.g. something like > http://github.com/vossg/OSGAddOnsGV) is to stage things first > this way. > > Ok, It sounds like you would like me to move the lib porting into > the > http://github.com/vossg/OSGAddOnsGV repo. I could put a remote branch > of this somewhere, or could/should I get write access to this one? not necessarily, OSGAddOnsGV was just an example of an external set of libs that can be build together with OpenSG or on top of an OpenSG installation. So you can keep it at your preferred location. Actually I would create a separate repository on github. I probably do it so you can see how this structure looks like. I will also use a clone of DevMaster to stage/store your core OpenSG changes that can not be externalized. > > One of the advantages is separating out the core changes. > > Changes to OpenSG itself could be ideally handled over github > and pulled independent of the rest. > > Also, once we have it running in this staging setup it is a > lot > easier to work with it and understand the implications. Moving > from the staging area into the main OpenSG tree is usually > not that difficult, for things that go into contrib it is > straight forward. It also should be able to handle external > dependencies, if not I want to fix this anyway. > > As a starter if you give me probably the weekend I could > look into what is already inside the sf git and try to > come up with a initial external setup suggestion. > > Should I wait for further information on this, or could I continue to > work on some of the porting on the remote branch I am using now? you should be able to work on the porting while I get a better idea and do the basic prep work. I would also like to take a little time to document the process. > If it would not be too difficult to move over to your inclusion > process, then I would like to continue the porting on my remote > branch. no it shouldn't. The good thing with being 14 hours ahead of you is that for the one point where things should move to the different structure it can be done overnight for you (if you want me to do it). > > Thanks for all of the input, I hope I haven't given you a headache > with all of the code and changes I have made on the remote branch. :) nope no worries, over the years one develops a good sense to find the key things inside larger path sets ;) kind regards gerrit ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
