Hi Andreas,
On Thu, 2003-10-16 at 08:50, Andreas Kopecki wrote:
>
> Well, but it would remove one of the biggest buggers. I don????t really
> mind extracting a node core and doing my stuff with it, but it is really
> strenuous to create just a simple node.... As for the CNP, I don't think
> it is a great idea as it would bloat the API even further and wouldn't
> help a beginner a bit. I think, it would just confuse and make things
> harder explain and to find in the docs.
OK, if simple things like this can make you happy I'm all for it. ;)
What about something like this:
template <class core, class coreptr>
NodePtr makeNode(void)
{
NodePtr n = Node::create();
coreptr c = core::create();
beginEditCP(n, Node::CoreFieldMask);
n->setCore(c);
endEditCP(n, Node::CoreFieldMask);
return n;
}
#define makeTransformNode() makeNode<Transform, TransformPtr>()
I would have preferred to just do the function, but having to put in the
class and the pointer looks pretty tedious. I couldn't find a way to get
to the pointer from the class, that would have made it possible. Gerrit,
did I miss something there? If not, could we put a typedef Ptr
<FCType>Ptr; into the FCs?
If we do that I would go for something like
NodePtr n = makeNode<Transform>();
Is that good enough? Alternatively we could add an optional Ptr pointer
argument to put the core pointer in:
TransformPtr t;
NodePtr n = makeNode<Transform>(&t);
> Speaking of the docs and beginners: Maybe it would be sensible to merge
> documentation of Class and ClassBase into one file (if possible at all).
> It would not be accurate, but much less clicking through hierarchies...
The only way I could find to make that happen is by making doxygen
include all the inherited members into the docs for every class. That
way you would get the Base class and everything else. Due to the way the
docs are generated some things would appear twice, but that was fine
with me. Couldn't get a majority in the core though, that's why we
changed it back.
I built the two alternative versions and put them at
http://www.opensg.org/doc_temp/Doc.Inherit/ and
http://www.opensg.org/doc_temp/Doc.NoInherit/.
Interesting places are
http://www.opensg.org/doc_temp/Doc.Inherit/classosg_1_1GeoPositions3f.html
http://www.opensg.org/doc_temp/Doc.Inherit/classosg_1_1Geometry.html
vs.
http://www.opensg.org/doc_temp/Doc.NoInherit/classosg_1_1GeoPositions3f.html
http://www.opensg.org/doc_temp/Doc.NoInherit/classosg_1_1Geometry.html
Take a look and tell us what you prefer.
Yours
Dirk
--
-- Dirk Reiners OpenSG Forum [EMAIL PROTECTED]
-- The OpenSG Open Source Scenegraph: http://www.opensg.org
-- Announcements: http://lists.sf.net/lists/listinfo/opensg-announce
-------------------------------------------------------
This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo
The Event For Linux Datacenter Solutions & Strategies in The Enterprise
Linux in the Boardroom; in the Front Office; & in the Server Room
http://www.enterpriselinuxforum.com
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
