Hi Gerrit,
Gerrit Voss wrote:
>> - Do we want to support child/parent linking with fields added to a
>> DynamicFieldAttachment ?
>
> not necessarily.
that sounds too much like a yes to me to be comfortable ignoring it at
the moment...
>> - Should the child pointer field be default constructible but
>> inoperable in that case ?
>
> yes, fields should stay default constructable.
ok, but default constructed child pointer fields will be completely
non-functional.
>> - The VRML loader is currently disabled in my tree as it has some unique
>> uses of FieldDescriptions. I have not yet looked into how to fix it, but
>> it seems less trivial than all the other places.
>
> Hmm, can you be more specific, I don't see where it does something not
> used anywhere else.
nevermind, I got it to compile, I just need to test if it also works ;)
> Anyway I don't see why the FieldDescriptions should
> change (given that the fields stay default constructable).
>
>> Since there has been
>> more than one VRML loader floating around, is the one in trunk the one
>> that will be used in 2 ?
>
> yes, we decided to keep the original 1.x loader and scrap my second try.
ok, I only wanted to make sure that it is the right thing I work on and
not something that gets thrown away anyways ;)
Thanks,
Carsten
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
