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

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

Murashov Gleb wrote:
>  
> On Wed, 2008-07-23, Braden McDaniel wrote:
>> node_type::create_node is a rather low-level operation from OpenVRML's
> 
>> perspective. That is not to say that you shouldn't be using it; just 
>> be aware that browser::create_vrml_from_stream may be an appropriate
> alternative.
> 
> I've used browser::create_vrml_from_stream successfully, but I can't
> understand, which scope got created node.
> 
> 	field_value_listener< mfnode >& fvl_add =
> group_node->event_listener< mfnode >("addChildren");
> 
> 	std::stringstream sss;
> 	sss << "DEF main_TS TouchSensor {}";
> 	mfnode::value_type nodes_for_mfnode =
> browser.create_vrml_from_stream(sss);
> 
> 	mfnode mfn(nodes_for_mfnode);
> 	fvl_add.process_event(mfn, 0.0);
> 
> 	...
> 
> 	node* f_n = root_scope.find_node("main_TS");
> 	// f_n == 0 :(
> 
> TouchSensor is created and works, but created node doesn't appear in
> root_scope. Where can I find that? Is there any possibility to manage
> this?

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).

Can you tell me more about what you're trying to accomplish? Perhaps 
there's another approach that would work better.

> 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. It just doesn't present the simplest 
interface for creating nodes from VRML text.

> Another thing. I've found small bug in openvrml-xembed and
> mozilla-plugin interaction. And I don't know how bug-tracking have to be
> used, so I write here. =)

OpenVRML uses the SourceForge tracker. Don't worry too much about 
getting the bug categorization exactly right; that can generally be 
adjusted ad hoc.

> openvrml-0.17.6\mozilla-plugin\src\openvrml.cpp : 442
> 	command << "new-stream " << ptrdiff_t(stream) << ' ' << type <<
> ' ' << stream->url << '\n';
> openvrml-0.17.6\mozilla-plugin\src\openvrml.cpp : 460
> 	command << "destroy-stream " << ptrdiff_t(stream) << '\n';
> 
> Signed type ptrdiff_t is using.
> 
> openvrml-0.17.6\src\openvrml-xembed\main.cpp : 149-151
> 	size_t stream_id;
> 	std::string type, url;
> 	command_line_stream >> stream_id >> type >> url;
> openvrml-0.17.6\src\openvrml-xembed\main.cpp : 172-173
> 	size_t stream_id;
> 	command_line_stream >> stream_id;
> 
> Unsigned type size_t is using.
> 
> That was reason my system crash during plug-in initialization. This
> happens from time to time.

Hm... Good point. This really should use size_t consistently.

This is probably worth going ahead and fixing; however, I'm in the 
middle of ripping out this pipe-based custom IPC solution in favor of 
D-Bus interfaces.

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