Re: [openvrml-develop] shared_ptr<scope> and scope*

[Braden M. <br...@en...>]

On Fri, 2008-08-15 at 16:32 +0400, Murashov Gleb wrote:
> > Braden McDaniel wrote:
> > openvrml::scope corresponds to a lexical scope for DEF/USE names.
> > As such, the nodes created from create_vrml_from_stream
> > have their own root scope that is distinct from the scene's.
> > The only way to get to this scope is through a node
> > (i.e., openvrml::node::scope).
> 
> I think that situation is strange, when creating named node by
> create_vrml_from_stream and not storing node reference, we don't have
> easy way to find that one. So, we have dependence between points in
> code: creating node and using node.

Well, the scopes are distinct because, as I said, they really do
correspond to lexical scopes. It is entirely permissible for a node in a
string given to create_vrml_from_stream to have the same DEF name as a
node already in the scene.

Note that the nodes you create with create_vrml_from_stream are not
automatically added to the scene. If you don't store a(n owning)
reference to them, *they will go away*. And if you want them to be in
the scene, you'll need to put them there.

If your goal is to replace the scene itself, you really should be using
browser::set_world. While it is possible to replace the scene's root
nodes by using create_vrml_from_stream followed by
browser::replace_world, this is not generally ideal because the scene's
URL doesn't change in that case.

> > Can you tell me more about what you're trying to accomplish?
> > Perhaps there's another approach that would work better.
> 
> I don't have question relate my task. I'm trying to do available
> openvrml API subset under Mozilla plug-in.

Wow... That's ambitious. Especially considering what a pain-in-the-ass
that must be given the current mode of IPC with openvrml-xembed.

>  Typical task which I solve is
> to create TouchSensor node for certain group node and to get TouchSensor
> events. I'm askink for better understanding =)
> 
> > I'm in the middle of ripping out this pipe-based custom IPC solution
> > in favor of D-Bus interfaces.
> 
> Could you tell me when this task will be finished?

Not precisely; but see my recent status posting on this. If things go
smoothly I could be done in a week. If I hit a bunch of problems and
life imposes other demands on me (I have an infant son), it could be
significantly longer.

I will check code into svn just as soon as I have something that's the
least bit usable. If it's too rough for the trunk, I'll put it on a
branch.

> >> Getting back to node_type::create_node(). If we can't use this 
> >> function outside library, it would be better to remove this one from 
> >> public interface?
> > I don't know of anything that prevents this function from being usable
> > by clients of libopenvrml.
> 
> Is there legal way to get shared_ptr<scope>&, which is necessary for
> using node_type::create_node()?

Either you create a new one or you use one you already created. If you
search for "new scope" in browser.cpp you'll see the various spots new
scopes get created during parsing.

As it stands, scopes really aren't run-time mutable. Rather, they are a
run-time *inspectable* reflection of an aspect of parse-time state.

Making them run-time mutable might be a good idea. But doing that is
going to involve coming up with some acceptable solutions to some
annoying problems. It will involve creating a correspondence between
scopes and run-time scene constructs and solving the problem of merging
scopes in some way that isn't too awful.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>