openvrml-develop — OpenVRML developers mailing list

Re: [openvrml-develop] make[3]: o: Command not found

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

Ben Hammett wrote:
> I have recently checked the most recent version of openVRML out of CVS, 
> and have follwed the instructions given in README.build_from_cvs.
> 
> Everything seems to work ok until step 4, where the make starts off ok 
> and then stops with the following error messages:
> o ../../../src/libopenvrml/openvrml 
> ./../../src/libopenvrml/openvrml/Vrml97Parser.g.
> make[3]: o: Command not found
> make[3]: [../../../src/libopenvrml/openvrml/Vrml97Parser.cpp] Error 127 
> (ignored)
> o ../../../src/libopenvrml/openvrml 
> ./../../src/libopenvrml/openvrml/Vrml97Parser.g.
> make[3]: o: Command not found
> make[3]: [../../../src/libopenvrml/openvrml/Vrml97Parser.hpp] Error 127 
> (ignored)
> make[3]: *** No rule to make target 
> `../../../src/libopenvrml/openvrml/Vrml97ParserTokenTypes.hpp', needed 
> by `all'.  Stop.
> make[3]: Leaving directory `/home/bhammett/openvrml/BUILD/src/libopenvrml'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/home/bhammett/openvrml/BUILD/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/bhammett/openvrml/BUILD'
> make: *** [all] Error 2
> 
> any help would be very much appreciated.

'o'? Okay, that's interesting.

I recently changed stuff to require that CVS users have antlr. The 
motivation for this was to get the generated sources out of the 
repository and out of changesets. The plan is to continue to include 
them in the tarball, so tarball users won't need antlr.

That said, I'm well aware that this isn't yet all working as it should.

For the moment, this should get you going. Install antlr; then invoke 
make like this:

   $ make ANTLR='java -cp /path/to/antlr.jar antlr.Tool'

Braden

[openvrml-develop] make[3]: o: Command not found

[Ben H. <ben...@sh...>]

I have recently checked the most recent version of openVRML out of CVS, 
and have follwed the instructions given in README.build_from_cvs.

Everything seems to work ok until step 4, where the make starts off ok 
and then stops with the following error messages:
o ../../../src/libopenvrml/openvrml 
../../../src/libopenvrml/openvrml/Vrml97Parser.g
make[3]: o: Command not found
make[3]: [../../../src/libopenvrml/openvrml/Vrml97Parser.cpp] Error 127 
(ignored)
o ../../../src/libopenvrml/openvrml 
../../../src/libopenvrml/openvrml/Vrml97Parser.g
make[3]: o: Command not found
make[3]: [../../../src/libopenvrml/openvrml/Vrml97Parser.hpp] Error 127 
(ignored)
make[3]: *** No rule to make target 
`../../../src/libopenvrml/openvrml/Vrml97ParserTokenTypes.hpp', needed 
by `all'.  Stop.
make[3]: Leaving directory `/home/bhammett/openvrml/BUILD/src/libopenvrml'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/bhammett/openvrml/BUILD/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/bhammett/openvrml/BUILD'
make: *** [all] Error 2

any help would be very much appreciated.

Thanks,

Ben

[openvrml-develop] Nonnative EXTERNPROTO support checked in

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

I've checked in support for nonnative EXTERNPROTOs; they're loaded
asynchronously, too.

That's the last major feature I plan on adding prior to the next release
(0.16.0). That release is probably a month or so off, still--maybe two.
In that time I'll be doing whatever bug fixing and polishing I
can--mostly making the Mozilla plug-in as usable as I can.

Also, Andrew Grieve has been working on preliminary X3D support. It is
likely that this will make it into the 0.16.0 release as well.

There's plenty that's not going to make it--fixing the Script node Java
binding comes to mind. But a lot of interesting things have been added
since 0.15, including:

      * a new input subsystem that allows applications to provide
        customized input sources;
      * use of multiple threads to asynchronously retrieve resources;
      * progressively rendered PNG and JPEG images;
      * the Mozilla plug-in now uses the Web browser to retrieve
        resources, which means it can leverage the browser's cache.

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

Re: [openvrml-develop] incompatibility between older and newer version of OpenVRML?

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

On Mon, 2005-11-21 at 09:02 +0100, jo...@pl... wrote:
> We have some vrml models. Before we used the older OpenVRML library 
> (don´t remember
> which version it was exactly),at least we had to change arVrml97* calls 
> to arVrml*
> calls) Now I´m using the newest one.

ar* isn't part of OpenVRML's API. Presumably it's something else you're
using which in turn depends on OpenVRML.

> What happens now is that some models are shown ok. But with some of 
> them my texture get a darker colour and it seems that some light is 
> turned off. But in my code nothing of all that. Has some syntax changed 
> between versions of OpenVRML or are there some incompatibilies? I have 
> read about the problem with CONVEX, which had to be changed to ccw. Are 
> there some more syntax changes?

You'd have to narrow the parameters of the question before I could
provide you with a useful response. Yes, OpenVRML has changed a lot over
the last several years. Bugs have been fixed, and other bugs have been
added.

OpenVRML attempts to implement the VRML97 spec; so there is a standard
of correctness that applies in most cases. If you're not sure whether
something is working correctly, please post a test case (the simpler the
better) and I can provide you with some feedback as to whether the
problem is with OpenVRML or your model. If you're already convinced
OpenVRML's doing something wrong, feel free to go ahead and file a bug
report.

PS: openvrml-develop permits posting only by subscribers in order to
curb spam. Please subscribe to the list if you intend to continue
posting.

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

[openvrml-develop] incompatibility between older and newer version of OpenVRML?

[<jo...@pl...>]

We have some vrml models=2E Before we used the older OpenVRML library =

(don=B4t remember
which version it was exactly)=2Cat least we had to change arVrml97* calls=
 =

to arVrml*
calls) Now I=B4m using the newest one=2E

What happens now is that some models are shown ok=2E But with some of =

them my texture get a darker colour and it seems that some light is =

turned off=2E But in my code nothing of all that=2E Has some syntax chang=
ed =

between versions of OpenVRML or are there some incompatibilies=3F I have =

read about the problem with CONVEX=2C which had to be changed to ccw=2E A=
re =

there some more syntax changes=3F

Re: [openvrml-develop] Considering renaming node_class

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

On Sat, 2005-11-19 at 16:25 -0500, Reed Hedges wrote:
> I looked at node_class a bit but don't remember exactly how it works,
> but "factory" does imply a specific way of operating.  Could a
> node_metatype in fact be a kind of node_type? Then you could just have
> "nothing but node_types all the way down" :)

A node_class is a factory for node_types. node_class and node_type have
distinct roles. A node_type identifies a subset of the interfaces that
can be supported by a node implementation and is a factory for nodes
that have those interfaces. The node_class gives the node implementation
identity and provides a way of creating node_types.

Different node types can share implementation logic--that's not unique
to OpenVRML; that's just the way VRML97 works. node_class is a place to
hang that shared implementation logic.

> Either way, but yes, I did find the whole idea of node_class a bit
> mysterious at first, partly because I didn't know what _class meant.

I agree it's vague. So is _metatype better? If not, then what?

> Most of us openvrml users won't need to deal with node_class anyway if
> we're not creating new types of nodes, right?  So the documentation
> could just say so and we could skip over it.

That's true to an extent; though API changes that will be going in soon
will raise its visibility a bit: I'll be making it possible to add and
retrieve node_classes to/from a browser instance. Most casual users
probably won't be interested in this functionality; but it does expose a
rather important dimension of flexibility to those who need it.

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

Re: [openvrml-develop] Considering renaming node_class

[Reed H. <re...@in...>]

I looked at node_class a bit but don't remember exactly how it works,
but "factory" does imply a specific way of operating.  Could a
node_metatype in fact be a kind of node_type? Then you could just have
"nothing but node_types all the way down" :)

Either way, but yes, I did find the whole idea of node_class a bit
mysterious at first, partly because I didn't know what _class meant.
Most of us openvrml users won't need to deal with node_class anyway if
we're not creating new types of nodes, right?  So the documentation
could just say so and we could skip over it.

Reed



Braden McDaniel wrote:
> I've been reminded recently that the distinction between "node_class"
> and "node_type" can be confusing; and I'm inclined to believe this is
> mostly because of how they're named. OOP tends to treat the terms
> "class" and "type" as synonyms. But in OpenVRML, a node_class is very
> different from a node_type.
> 
> I believe node_type is pretty accurately named. It corresponds to what
> the VRML97 spec calls a "node type". node_class, on the other hand,
> doesn't exactly correspond to anything in the spec. A concrete
> node_class provides a sort of foundation for the implementation of a
> suite of node_types that share that implementation. As such, it is
> closest to the VRML spec's concept of a PROTO. However, while a PROTO
> could be considered a "kind of" node_class (and in fact OpenVRML
> implements PROTOs that way), not all node_classes are PROTOs.
> 
> So I am considering renaming "node_class". The frontrunner in my mind at
> the moment is "node_metatype". This class is responsible for creating
> node_types; and it can create n! distinct node_types, where n is the
> number of node interfaces supported by the node implementation.
> 
> "node_type_factory" has also been suggested. It is accurate; this class
> is a factory for node_types. However, it strikes me as less expressive
> than "node_metatype".
> 
> Opinions? Other suggestions?
> 
> Braden
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
> Register for a JBoss Training Course.  Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop

[openvrml-develop] Considering renaming node_class

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

I've been reminded recently that the distinction between "node_class" 
and "node_type" can be confusing; and I'm inclined to believe this is 
mostly because of how they're named. OOP tends to treat the terms 
"class" and "type" as synonyms. But in OpenVRML, a node_class is very 
different from a node_type.

I believe node_type is pretty accurately named. It corresponds to what 
the VRML97 spec calls a "node type". node_class, on the other hand, 
doesn't exactly correspond to anything in the spec. A concrete 
node_class provides a sort of foundation for the implementation of a 
suite of node_types that share that implementation. As such, it is 
closest to the VRML spec's concept of a PROTO. However, while a PROTO 
could be considered a "kind of" node_class (and in fact OpenVRML 
implements PROTOs that way), not all node_classes are PROTOs.

So I am considering renaming "node_class". The frontrunner in my mind at 
the moment is "node_metatype". This class is responsible for creating 
node_types; and it can create n! distinct node_types, where n is the 
number of node interfaces supported by the node implementation.

"node_type_factory" has also been suggested. It is accurate; this class 
is a factory for node_types. However, it strikes me as less expressive 
than "node_metatype".

Opinions? Other suggestions?

Braden

Re: [openvrml-develop] TEXT Node

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

On Thu, 2005-11-17 at 12:39 +0100, Maurizio Pellegrini wrote:
> I'm using openvrml 0.15.9 under windows but the text nodes don't
> appear if i try to wacth them with lookat (or cortona client)...
> It's just me or this feature doesn't work?

<http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=86860&group_id=7151&group_project_id=2579>

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

[openvrml-develop] TEXT Node

[Maurizio P. <mi...@gm...>]

I'm using openvrml 0.15.9 under windows but the text nodes don't
appear if i try to wacth them with lookat (or cortona client)...
It's just me or this feature doesn't work?

Re: [openvrml-develop] How to Create a new Viewpoint

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

vr...@he... wrote:
> Hi Braden,
> 
> thanks for the fast response.
> 
> Braden McDaniel <br...@en...> wrote:
> 
>>> i would like to add a new viewport_node to the browser with a given 
>>> field of
>>> view.
>>> Or is it possible to change the viewport of the active viewpoint 
>>> node. I've
>>> searched for this topic, but found nothing helpfull.
>>
>>
>> One way is to create a new node with browser::create_vrml_from_stream
>> and add it to the scene.
> 
> 
> The only possibilty i found, was to add the node to the browser so I 
> tried it
> this way, but there must be something wrong, because it crashes later 
> when the
> viewpoint is set with set_viewpoint during the rendering. I'm not knowing
> OpenVrml very well, so please give me a hint to the right direction. 
> Here is my
> code:
> 
> vector<node_ptr> nodes = myBrowser->create_vrml_from_stream(nodeStream);
> 
> viewpoint_node* viewpointPtr = node_cast<viewpoint_node*>(nodes[0].get());

At this point you have a viewpoint_node, but it's not part of any scene. 
node::initialize needs to be called for it to be added to a scene.

> myBrowser->add_viewpoint(*viewpointPtr);
> myBrowser->active_viewpoint(*viewpointPtr);

Unfortunately, browser::add_viewpoint doesn't do what you need. All it 
does is make the browser aware of a viewpoint_node for the purpose of 
potentially presenting a list of them in a user interface.

This is a part of the API that could really use some more thought, I'm 
afraid. The bound node stack logic has been deliberately factored out of 
the core runtime and into the node implementations because I want the 
potential to provide a less cumbersome implementation of an 
openvrml::viewpoint_node than what is required for VRML97. Making that 
compatible with a straightforward API remains a challenge. Suffice it to 
say that browser::add_viewpoint really shouldn't be part of the public 
API. It gets called as a side effect of calling node::initialize.

Changing nodes after they're created involves sending them events. You 
need to get the event_listener corresponding to the eventIn you're 
interested in and call field_value_listener<FieldValue>::process_event. 
Note that there are typedefs for the field_value_listener instances you 
might be interested in, so you can do something like this:

   sfvec3f_listener & listener =
     dynamic_cast<sfvec3f_listener &>(
       viewpointPtr->event_listener("set_position"));
   listener.process_event(new_pos, time);

"time" you probably want to get from browser::current_time.

Oh, if you're using the CVS version, the first part of the above is a 
bit tidier:

   sfvec3f_listener & listener =
     viewpointPtr->event_listener<sfvec3f>("set_position");

To make the Viewpoint active, you should send a "true" sfbool value to 
the listener corresponding to "set_bind".

(And note that as in VRML, you can elide the "set_" prefix on the 
eventIn identifiers if you so desire.)

> Another solution for my problem, would be to change the position and the 
> field
> of view of the active viewpoint. But I didn't found something to change the
> properties of myBrowser->active_viewpoint().

This will be a bit simpler since you don't need to deal with explicitly 
initializing a node. But as above, you want to send the node events--in 
this case, to the event_listeners corresponding to "set_position" and 
"set_fieldOfView".

> To be honest for me the
> implementation of the nodes is a little bit confusing (i am not such a
> CodeGuru)and I am not quit sure how it works. Maybe I will have some 
> time this
> weekend to go through the code to understand it a little bit better.

For the moment, I'd actually steer you away from looking too hard at the 
way the nodes in vrml97node.cpp implement this stuff. There is a good 
deal of template and pointer-to-member magic that is there to minimize 
redundant code when implementing a large number of nodes--but it can 
make it harder to see the Big Picture.

I can provide more exposition if necessary. However, I'm inclined to 
drop useful hints as I tend to be interested in seeing how well the API 
explains itself.

>> PS: The openvrml-develop mailing list permits posting only by
>> subscribers in order to curb spam. Please subscribe to the list if you
>> intend to continue posting.
> 
> Just used the wrong email address, Sorry for that!

Perhaps you have discovered this already; but it is possible to 
subscribe multiple e-mail addresses and disable mail delivery to all but 
one of them (using the MailMan Web interface).

Braden

Re: [openvrml-develop] How to Create a new Viewpoint

[<vr...@he...>]

Hi Braden,

thanks for the fast response.

Braden McDaniel <br...@en...> wrote:
>> i would like to add a new viewport_node to the browser with a given field of
>> view.
>> Or is it possible to change the viewport of the active viewpoint node. I've
>> searched for this topic, but found nothing helpfull.
>
> One way is to create a new node with browser::create_vrml_from_stream
> and add it to the scene.

The only possibilty i found, was to add the node to the browser so I tried it
this way, but there must be something wrong, because it crashes later when the
viewpoint is set with set_viewpoint during the rendering. I'm not knowing
OpenVrml very well, so please give me a hint to the right direction. 
Here is my
code:

vector<node_ptr> nodes = myBrowser->create_vrml_from_stream(nodeStream);

viewpoint_node* viewpointPtr = node_cast<viewpoint_node*>(nodes[0].get());
myBrowser->add_viewpoint(*viewpointPtr);
myBrowser->active_viewpoint(*viewpointPtr);

Another solution for my problem, would be to change the position and the field
of view of the active viewpoint. But I didn't found something to change the
properties of myBrowser->active_viewpoint(). To be honest for me the
implementation of the nodes is a little bit confusing (i am not such a
CodeGuru)and I am not quit sure how it works. Maybe I will have some time this
weekend to go through the code to understand it a little bit better.

Thanks a lot
Joerg

> PS: The openvrml-develop mailing list permits posting only by
> subscribers in order to curb spam. Please subscribe to the list if you
> intend to continue posting.

Just used the wrong email address, Sorry for that!

Re: [openvrml-develop] How to Create a new Viewpoint

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

On Tue, 2005-11-15 at 00:52 +0100, jo...@he... wrote:
> Hi all,
> 
> i would like to add a new viewport_node to the browser with a given field of
> view.
> Or is it possible to change the viewport of the active viewpoint node. I've
> searched for this topic, but found nothing helpfull.

One way is to create a new node with browser::create_vrml_from_stream
and add it to the scene.

Another is to get the "Viewpoint" node_type from the scope and create a
new node from it:

        your_browser.root_nodes()[0]->scope()->find_type("Viewpoint")->create_node(...);

> Is it also possible to change the absolute transformation of a viewpoint, not
> relative to the active viewpoint node? At the moment i'm resetting the current
> viewpoint, and then change the transformation.

I'm not sure what you mean here because you don't appear to be using
VRML's nomenclature.

Changes to the user view are always relative to the active Viewpoint
node. You can change the position and orientation of a Viewpoint node;
or you can change the translation and rotation of one of its parent
Transform nodes.

PS: The openvrml-develop mailing list permits posting only by
subscribers in order to curb spam. Please subscribe to the list if you
intend to continue posting.

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

Re: [openvrml-develop] Don't update just yet

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

On Mon, 2005-11-14 at 16:55 -0500, Braden McDaniel wrote:
> If you have updated since 11/7, I advise against doing it again just 
> now. See:
> 
> <https://sf.net/tracker/index.php?func=detail&aid=1356868&group_id=1&atid=200001>
> 
> This issue has been resolved on SF's side; however, the data in CVS is 
> now a bit old. I have the missing bits in local working copies and I 
> will commit them later today. I'll follow up here when I'm done.

I'm done. You should probably blow away ChangeLog and let cvs update
replace it.

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

[openvrml-develop] How to Create a new Viewpoint

[<jo...@he...>]

Hi all,

i would like to add a new viewport_node to the browser with a given field of
view.
Or is it possible to change the viewport of the active viewpoint node. I've
searched for this topic, but found nothing helpfull.
Is it also possible to change the absolute transformation of a viewpoint, not
relative to the active viewpoint node? At the moment i'm resetting the current
viewpoint, and then change the transformation.

Any hints are most welcome

Cheers
Joerg

[openvrml-develop] Don't update just yet

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

If you have updated since 11/7, I advise against doing it again just 
now. See:

<https://sf.net/tracker/index.php?func=detail&aid=1356868&group_id=1&atid=200001>

This issue has been resolved on SF's side; however, the data in CVS is 
now a bit old. I have the missing bits in local working copies and I 
will commit them later today. I'll follow up here when I'm done.

Braden

Re: [openvrml-develop] black screen with mozilla plugin

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

On Wed, 2005-11-09 at 10:36 +0100, Tomasz Chmielewski wrote:
> I just compiled and installed openvrml-0.15.10, and copied these three 
> files from /usr/local/lib/mozilla/plugins: openvrml.la, openvrml.so, 
> openvrml.xpt to /usr/lib/mozilla/plugins.
> 
> It seems that mozilla recognizes the plugin, as it is displayed in 
> about:plugins.
> 
> However when I want to view a page that has some vrml content, the space 
> where it is located is black, and that's it.
> The plugin probably works, because I can see the mouse pointer change 
> when I do a left/middle/right click..
> 
> I tried the binary packages, and the effect was the same.
> 
> Is there a way to get around this issue?

Most likely OpenVRML has some problem with the content. Try a simple
test world with the plug-in to see if it's working at all. Assuming
that's the case, feel free to file a bug report regarding the content
OpenVRML isn't handling.

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

RE: [openvrml-develop] black screen with mozilla plugin

[Dimitry K. <dim...@gm...>]

I do not use mozilla plugin but I usually get the similar behavior when
my scene has no Appearance node. Just my two cents.
--
 Dima

> -----Original Message-----
> From: ope...@li... 
> [mailto:ope...@li...] On 
> Behalf Of Tomasz Chmielewski
> Sent: Wednesday, November 09, 2005 11:37 AM
> To: ope...@li...
> Subject: [openvrml-develop] black screen with mozilla plugin
> 
> 
> I just compiled and installed openvrml-0.15.10, and copied 
> these three 
> files from /usr/local/lib/mozilla/plugins: openvrml.la, openvrml.so, 
> openvrml.xpt to /usr/lib/mozilla/plugins.
> 
> It seems that mozilla recognizes the plugin, as it is displayed in 
> about:plugins.
> 
> However when I want to view a page that has some vrml 
> content, the space 
> where it is located is black, and that's it.
> The plugin probably works, because I can see the mouse pointer change 
> when I do a left/middle/right click..
> 
> I tried the binary packages, and the effect was the same.
> 
> Is there a way to get around this issue?
> 
> 
> 
> -- 
> Tomek
> http://wpkg.org
> WPKG - software deployment and upgrades with Samba
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App 
> Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> openvrml-develop mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openvrml-develop
> 

[openvrml-develop] black screen with mozilla plugin

[Tomasz C. <ma...@wp...>]

I just compiled and installed openvrml-0.15.10, and copied these three 
files from /usr/local/lib/mozilla/plugins: openvrml.la, openvrml.so, 
openvrml.xpt to /usr/lib/mozilla/plugins.

It seems that mozilla recognizes the plugin, as it is displayed in 
about:plugins.

However when I want to view a page that has some vrml content, the space 
where it is located is black, and that's it.
The plugin probably works, because I can see the mouse pointer change 
when I do a left/middle/right click..

I tried the binary packages, and the effect was the same.

Is there a way to get around this issue?



-- 
Tomek
http://wpkg.org
WPKG - software deployment and upgrades with Samba

Re: [openvrml-develop] [patch] bringing gtklookat to a better state

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

On Wed, 2005-11-02 at 16:59 +0100, Sam Hocevar wrote:
> On Wed, Nov 02, 2005, Braden McDaniel wrote:
> > On Wed, 2005-11-02 at 15:13 +0100, Sam Hocevar wrote:
> > >    Attached patch adds support for GTK-2.0 and openvrml5 (0.15.10 API)
> > > to gtklookat. It's not extremely elegant and disables a few things, but
> > > at least the program builds and runs, so I thought it might be useful.
> > 
> > Unfortunately there's no one maintaining gtklookat right now. Are you
> > interested in applying this yourself and making a new release?
> 
>    Why not. I'm all for applying the patch myself, but a release will
> need more work. Let me first try to put together a nicer patch and
> re-enable the missing features, so that I don't volunteer for something
> I won't find the time to carry to the end.

Ping me when/if you're ready for this and I'll add you to the
SourceForge project.

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

Re: [openvrml-develop] [patch] bringing gtklookat to a better state

[Sam H. <sa...@zo...>]

On Wed, Nov 02, 2005, Braden McDaniel wrote:
> On Wed, 2005-11-02 at 15:13 +0100, Sam Hocevar wrote:
> >    Attached patch adds support for GTK-2.0 and openvrml5 (0.15.10 API)
> > to gtklookat. It's not extremely elegant and disables a few things, but
> > at least the program builds and runs, so I thought it might be useful.
> 
> Unfortunately there's no one maintaining gtklookat right now. Are you
> interested in applying this yourself and making a new release?

   Why not. I'm all for applying the patch myself, but a release will
need more work. Let me first try to put together a nicer patch and
re-enable the missing features, so that I don't volunteer for something
I won't find the time to carry to the end.

-- 
Sam.

Re: [openvrml-develop] [patch] bringing gtklookat to a better state

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

On Wed, 2005-11-02 at 15:13 +0100, Sam Hocevar wrote:
>    Attached patch adds support for GTK-2.0 and openvrml5 (0.15.10 API)
> to gtklookat. It's not extremely elegant and disables a few things, but
> at least the program builds and runs, so I thought it might be useful.

Unfortunately there's no one maintaining gtklookat right now. Are you
interested in applying this yourself and making a new release?

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

[openvrml-develop] [patch] bringing gtklookat to a better state

[Sam H. <sa...@zo...>]

   Attached patch adds support for GTK-2.0 and openvrml5 (0.15.10 API)
to gtklookat. It's not extremely elegant and disables a few things, but
at least the program builds and runs, so I thought it might be useful.

Regards,
-- 
Sam.

[openvrml-develop] ANN: openvrml-commit mailing list

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

I've created a new mailing list for commit e-mail. This will probably be
of interest to only a handful of people other than me; but if you're one
of them, you can subscribe here:

        <http://lists.sourceforge.net/lists/listinfo/openvrml-commit>

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

Re: [openvrml-develop] build-time memory consumption

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

Andrew Grieve wrote:

 > I think vrml97node.cpp could be split up if there were two registry
 > functions (have a register_node_classes1() and a
 > register_node_classes2()). This would break the file into 2 smaller
 > ones without the need for additional exported functions (except for
 > the extra register_node_classes)

I'm not happy with this solution because the split would carry over into 
the modules, yielding two modules instead of one. This is a rather ugly 
change to runtime characteristics to solve a compile-time problem.

Braden

PS: Please be more conscientious in your quoting.