From dbertini at lxg0402.gsi.de Thu Sep 5 15:46:23 2002 From: dbertini at lxg0402.gsi.de (Denis Bertini) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt Message-ID: Hi all, I use sucessfully you Coin Inventor clone together with a CERN standard library ROOT (http://root.cern.ch) used by the scientific community. My only problem ( very small one indeed !) is that to merge both framework i need to derive from your SoQt class. But the constructor SoQt::SoQt and dtor SoQt::~SoQt are declared private and this for me problematic. Is it for your a big design change if you would put "protected" instead of "private" for SoQt ctor and dtor? thanks a lot for your response, Bertini, Denis, Dr. Phone: +49-6159-71 2240 FAX: +49-6159-71 2986 Department: Datenverarbeitung und Experimentelektronik Location: SB3 2.243 E-Mail: D.Bertini@gsi.de ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Thu Sep 5 16:03:25 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: Denis Bertini's message of "Thu, 5 Sep 2002 15:46:23 +0200 (CEST)" References: Message-ID: <511y884jpu.fsf@nfs.trh.sim.no> Denis Bertini writes: > I use sucessfully you Coin Inventor clone together with a CERN > standard library ROOT (http://root.cern.ch) used by the scientific > community. Nice. Feel free to send us screenshots of the Higgs particle. :-) > My only problem ( very small one indeed !) is that to merge both > framework i need to derive from your SoQt class. Why is that? Because you want to control the event loop? > But the constructor SoQt::SoQt and dtor SoQt::~SoQt are declared > private and this for me problematic. Is it for your a big design > change if you would put "protected" instead of "private" for SoQt > ctor and dtor? Actually, that wouldn't really make any sense, since the SoQt class is fully static. Ie it only contains static methods, and is not supposed to ever be instantiated. This is also why the constructor and destructor are private -- to protect the application programmer from making the mistake of instantiating objects from it. Let us know what the exact problem you are trying to solve is, and we'll see if we can figure out a solution. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From dbertini at lxg0402.gsi.de Thu Sep 5 17:02:02 2002 From: dbertini at lxg0402.gsi.de (Denis Bertini) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: <511y884jpu.fsf@nfs.trh.sim.no> Message-ID: On 5 Sep 2002, Morten Eriksen wrote: > Denis Bertini writes: > > > I use sucessfully you Coin Inventor clone together with a CERN > > standard library ROOT (http://root.cern.ch) used by the scientific > > community. > > Nice. Feel free to send us screenshots of the Higgs particle. :-) Ok, as soon as i find it i will send you a Open-inventor Higgs screenshots ! > > > My only problem ( very small one indeed !) is that to merge both > > framework i need to derive from your SoQt class. > > Why is that? Because you want to control the event loop? > Exactly i need to control it. > > But the constructor SoQt::SoQt and dtor SoQt::~SoQt are declared > > private and this for me problematic. Is it for your a big design > > change if you would put "protected" instead of "private" for SoQt > > ctor and dtor? > > Actually, that wouldn't really make any sense, since the SoQt class is > fully static. Ie it only contains static methods, and is not supposed > to ever be instantiated. This is also why the constructor and > destructor are private -- to protect the application programmer from > making the mistake of instantiating objects from it. > I Know that ! But in my case, i need to merge a framework that contains also an specific event loop and the fastest solution i found is to derive from SoQt but in that case in need protected not private. If the ctor of SoQt is protected, nobody can make another instance of it , the only way will be to derive which should be in principle possible. > Let us know what the exact problem you are trying to solve is, and As i said , my problem is solved when changing "private" to "protected" in ctor and dtor of SoQt which will allows inheritance. In that way ( more general way ) one can think, like i am doing, to extend SoQt module. regards, Denis ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Thu Sep 5 17:17:04 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: Denis Bertini's message of "Thu, 5 Sep 2002 17:02:02 +0200 (CEST)" References: Message-ID: <51znuwmpov.fsf@nfs.trh.sim.no> Denis Bertini writes: > > [Morten] > > Nice. Feel free to send us screenshots of the Higgs particle. :-) > > Ok, as soon as i find it i will send you a Open-inventor Higgs > screenshots ! Excellent! We don't mind if you make one of tachyons or gravitons either, by the way. ;-) > > Why is that? Because you want to control the event loop? > > Exactly i need to control it. I'm not aware of any SoQt-based projects where it's done yet, but I believe it should be fairly straightforward: just don't call SoQt::mainLoop(). Then instead, you can take control of the Qt event loop yourself in any way you like. SoQt::mainLoop() simply looks like this: void SoQt::mainLoop(void) { (void) qApp->exec(); SoQt::done(); } ..so just do the event loop thing yourself, and explicitly invoke SoQt::done() on exit to clean up SoQt's resource usage. > [...] in my case, i need to merge a framework that contains also an > specific event loop [...] Then just run that event loop, and don't call SoQt::mainLoop(). (As I said, I haven't tested this, but I think it should work. If it doesn't, we'd be very interested to know how it fails for you, as that would likely be a bug to be fixed.) > and the fastest solution i found is to derive from SoQt but in that > case in need protected not private. If the ctor of SoQt is > protected, nobody can make another instance of it , the only way > will be to derive which should be in principle possible. I don't think deriving from SoQt is going to help you in any way..? What exactly were you planning to do in the derived class? Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From dbertini at lxg0402.gsi.de Thu Sep 5 19:54:40 2002 From: dbertini at lxg0402.gsi.de (Denis Bertini) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: <51znuwmpov.fsf@nfs.trh.sim.no> Message-ID: On 5 Sep 2002, Morten Eriksen wrote: > Denis Bertini writes: > > > > [Morten] > > > Nice. Feel free to send us screenshots of the Higgs particle. :-) > > > > Ok, as soon as i find it i will send you a Open-inventor Higgs > > screenshots ! > > Excellent! We don't mind if you make one of tachyons or gravitons > either, by the way. ;-) woaah i am really impressed by your physic background !! > > > > Why is that? Because you want to control the event loop? > > > > Exactly i need to control it. > > I'm not aware of any SoQt-based projects where it's done yet, but I > believe it should be fairly straightforward: just don't call > SoQt::mainLoop(). Then instead, you can take control of the Qt event > loop yourself in any way you like. > > SoQt::mainLoop() simply looks like this: > > void > SoQt::mainLoop(void) > { > (void) qApp->exec(); > SoQt::done(); > } > > ..so just do the event loop thing yourself, and explicitly invoke > SoQt::done() on exit to clean up SoQt's resource usage. > > > [...] in my case, i need to merge a framework that contains also an > > specific event loop [...] > > Then just run that event loop, and don't call SoQt::mainLoop(). > > (As I said, I haven't tested this, but I think it should work. If it > doesn't, we'd be very interested to know how it fails for you, as that > would likely be a bug to be fixed.) > > > and the fastest solution i found is to derive from SoQt but in that > > case in need protected not private. If the ctor of SoQt is > > protected, nobody can make another instance of it , the only way > > will be to derive which should be in principle possible. > > I don't think deriving from SoQt is going to help you in any way..? > What exactly were you planning to do in the derived class? > > Regards, > Morten > Well all that is nice but let me explain more in detail my particular case. I do not use QApplication class of Qt but my "own" class derived from that Qt based class let say MyQApplication. This customized class reimplement the Qt event loop in order to interface another "event loop" from a external framework and this works nice. Now in SoQt the event loop use of course the natice QApplication, In my case i need to use a derived class, so deriving again MySoQt i can do that and its work fine. Only problem this private ctor and dtor of your class SoQt: i need to transform private to protected. Now if it is impossible to change it in your Coin lib i could just copy this class and change myself this privilege, but it is not nice from the maintenance point of view of course. But tell me, Why it is so dramatic to change a private to protected for the ctor and dtor of your SoQt class? Regards Denis ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 6 08:31:40 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: Denis Bertini's message of "Thu, 5 Sep 2002 19:54:40 +0200 (CEST)" References: Message-ID: <51fzwn633n.fsf@nfs.trh.sim.no> Denis Bertini writes: > I do not use QApplication class of Qt but my "own" class derived > from that Qt based class let say MyQApplication. [...] Now in SoQt > the event loop use of course the natice QApplication, [...] Actually, no. It should use your MyQApplication, if you initialize the other framework (which includes Qt library initialization, I assume) and SoQt in the right order. First initialize the other stuff, so that an instance of MyQApplication has been set up. Then run SoQt::init(). SoQt will then automatically pick up a pointer to your MyQApplication instance through the global qApp pointer from Qt, and use that. > But tell me, Why it is so dramatic to change a private to protected > for the ctor and dtor of your SoQt class? Because, as I said, the SoQt class is _not_ supposed to be instantiated -- it's completely static. There is nothing you can do with a derived SoQt class that you can not do in some other, more "correct" way. It sounds like you have already derived SoQt into a new class, where you are doing _something_. May we see the code of the new, derived class? I'm sure we could advise on how to accomplish what it's doing without changing the API of SoQt. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From dbertini at lxg0402.gsi.de Fri Sep 6 09:47:40 2002 From: dbertini at lxg0402.gsi.de (Denis Bertini) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: <51fzwn633n.fsf@nfs.trh.sim.no> Message-ID: Hi, Morten ! On 6 Sep 2002, Morten Eriksen wrote: > It sounds like you have already derived SoQt into a new class, where > you are doing _something_. May we see the code of the new, derived > class? I'm sure we could advise on how to accomplish what it's doing > without changing the API of SoQt. > yes i did and it works, of course it seems not to follows perfectly the SoQt API philosophy so in attachment i give you the class called SoQtROOT that i have implemented. If you could advice me how to do the same stuff in a better way it will be very nice for me ! thanks in advance, Denis -------------- next part -------------- A non-text attachment was scrubbed... Name: SoQtRoot.h Type: text/x-chdr Size: 931 bytes Desc: Url : /pipermail/coin-discuss/attachments/20020906/77c0e917/SoQtRoot.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: SoQtRoot.cpp Type: text/x-c++src Size: 5360 bytes Desc: Url : /pipermail/coin-discuss/attachments/20020906/77c0e917/SoQtRoot-0001.bin From mortene at sim.no Fri Sep 6 10:46:57 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: Denis Bertini's message of "Fri, 6 Sep 2002 09:47:40 +0200 (CEST)" References: Message-ID: <5165xj5wu6.fsf@nfs.trh.sim.no> Denis Bertini writes: > [...] in attachment i give you the class called SoQtROOT that i have > implemented. If you could advice me how to do the same stuff in a > better way it will be very nice for me ! As far as I can tell, you can do what I said earlier: just allocate your QRootApplication in the application code, initialize SoQt with SoQt::init() _after_ that has happened, and drop the SoQtRoot class altogether. Should work like a charm. If you have any problems, let us know. By the way, it looks like you might be using an old version of SoQt? Note that version 1.0.1 is available. You could stumble into an old bug in QApplication-related code if you don't upgrade to the latest. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From dbertini at lxg0402.gsi.de Fri Sep 6 11:47:10 2002 From: dbertini at lxg0402.gsi.de (Denis Bertini) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: <5165xj5wu6.fsf@nfs.trh.sim.no> Message-ID: Ok Morten, I am following your advice and i have to confess it works ... like a charm ! And i use the release version of SoQt now. So now i will not modify and/or derive any of the SoQt base class i will just use my special qApp pointer. Thanks a lot for your nice advice ... with this i gain a lot in maintenance problem. If your are interested in such a work, i can tell you more about my plans . I find it interesting to merge those package because it offer some nice features for the user to be used in the same application for example 1) powerful 2D-3D histograming possibility 2) powerful data-structure for large scale data analysis ( the one used by the physic community) 3) powerful 3D graphics from Coin Inventor clone. All in one make life easier for the physicist and sounds very attractive ! Again thanks a lot for advising me ! Denis On 6 Sep 2002, Morten Eriksen wrote: > Denis Bertini writes: > > > [...] in attachment i give you the class called SoQtROOT that i have > > implemented. If you could advice me how to do the same stuff in a > > better way it will be very nice for me ! > > As far as I can tell, you can do what I said earlier: just allocate > your QRootApplication in the application code, initialize SoQt with > SoQt::init() _after_ that has happened, and drop the SoQtRoot class > altogether. > > Should work like a charm. If you have any problems, let us know. > > By the way, it looks like you might be using an old version of SoQt? > Note that version 1.0.1 is available. You could stumble into an old > bug in QApplication-related code if you don't upgrade to the latest. > > Regards, > Morten > ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 6 12:03:47 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:39 2005 Subject: [coin-discuss] Problem linked to SoQt In-Reply-To: Denis Bertini's message of "Fri, 6 Sep 2002 11:47:10 +0200 (CEST)" References: Message-ID: <51it1jph8c.fsf@nfs.trh.sim.no> Denis Bertini writes: > Thanks a lot for your nice advice ... with this i gain a lot in > maintenance problem. That's what I would expect, yes. You also avoid being dependent on any internal intricacies of SoQt which could change for future releases, which of course is a good thing. > If your are interested in such a work, i can tell you more about my > plans. I find it interesting to merge those package because it offer > some nice features for the user to be used in the same application > for example > > 1) powerful 2D-3D histograming possibility > 2) powerful data-structure for large scale data > analysis ( the one used by the physic community) > 3) powerful 3D graphics from Coin Inventor clone. This does indeed sound very interesting. If you have done or will be doing a presentation of the system in any context (internal company presentation, at a conference, whatever), we would love to have a copy formatted for the web as a "Coin related" case study on coin3d.org. And we love juicy screenshots, of course. Higgs boson or not. So feel free to let us know if you would like a reserved spot on our Coin www pages to present the software. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From pdebanne at justine.umontreal.ca Sat Sep 7 03:45:50 2002 From: pdebanne at justine.umontreal.ca (=?iso-8859-1?Q?Philippe_Debann=E9?=) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Problem with reimplemented processSoEvent() and picking Nurbs Message-ID: <009001c25610$4e58c0a0$6951800a@hsj.qc.ca> Hello, I have a curious problem with picking Nurbs objects (e.g. SoNurbsCurve, SoIndexedNurbsSurface, etc) in a 3D viewer of my own class which I derive from SoQtExaminerViewer. The problem occurs when the following conditions are met: (1) My class, e.g. MyViewer, reimplements processSoEvent() and calls the inherited method, i.e.: SbBool MyViewer::processSoEvent(const SoEvent * const inEvent) { SbBool processed = SoQtExaminerViewer::processSoEvent(inEvent); (...) } (2) The viewer is in Interact mode, i.e. setViewing(false); (3) I select a nurbs object, i.e. left-mouse-click event on top of object. This provokes the following error (in Debug configuration) ---------------------------------- File: i386\chkesp.c Line: 42 Value of ESP not properly saved accross a function call. (...) ---------------------------------- My platform is as follows: ================================= WinNT 4.0 MSVC 6.0 SP5 Coin 1.0.2 precompiled SDK SoQt v 0.10.0 (2002-05-24 source snapshot) ================================= Below I provide the call stack in MSVC debugger. Has anyone else encountered this problem? As far as I can tell it only happens with nurbs shapes, so I wonder if it's related to the superglu embedded in Coin. But then, why does it only happen when I derive my own viewer class? Am I doing something wrong? Any ideas would be appreciated. Regards, Philippe Debann? Associ? de recherche Groupe LIS3D/LMBCAO, H?pital Ste-Justine Montr?al, Qu?bec t?l.:: (514) 345-4931 poste 2597 courriel : pdebanne@justine.umontreal.ca ================================================ MSVCRTD! _chkesp + 46 bytes MyViewer::processSoEvent(const SoEvent * const 0x06d05e90) line 230 SoQtRenderArea::processEvent(QEvent * 0x0012fb80 {type=MouseButtonPress}) line 1517 + 18 bytes SoQtGLWidget::eventFilter(QObject * 0x06d09eb0 {class="SoQtGLArea" name=""}, QEvent * 0x0012fb80 {type=MouseButtonPress}) line 613 SoQtFullViewer::eventFilter(QObject * 0x06d09eb0 {class="SoQtGLArea" name=""}, QEvent * 0x0012fb80 {type=MouseButtonPress}) line 662 QT-MT304! 39d53b36() QT-MT304! 39d53a9c() SoQtGLArea::event(QEvent * 0x0012fb80 {type=MouseButtonPress}) line 159 QT-MT304! 39d277d6() QT-MT304! 39d27450() QT-MT304! 39d05a2b() QT-MT304! 39d095ad() USER32! 77e72c6a() USER32! 77e72cf5() OPENGL32! 755ba950() USER32! 77e72c6a() USER32! 77e72cf5() S3MICD! 695675bb() ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From pdebanne at justine.umontreal.ca Mon Sep 9 22:03:13 2002 From: pdebanne at justine.umontreal.ca (=?iso-8859-1?Q?Philippe_Debann=E9?=) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQtObject no longer inherits QObject ?? Message-ID: <002501c2583b$f07ca310$6951800a@hsj.qc.ca> Hello all, I just noticed that since SoQt 1.0.0 (I think), SoQtObject no longer inherits QObject. It seems to me that this is a significant design change; what is the reason for it? And if I want my own viewer subclass to have signals and slots, must I now use multiple inheritance?, e.g. class MyViewer : public SoQtExaminerViewer, public QObject { Q_OBJECT SOQT_OBJECT_HEADER(MyViewer , SoQtExaminerViewer); (...) }; Also, is the inheritance of QObject somehow 'configure'able ? Thanks, Philippe Debann? Research Associate Groupe LIS3D/LMBCAO Ste-Justine Hospital Montreal, Quebec tel.:: (514) 345-4931 ext. 2597 email : pdebanne@justine.umontreal.ca ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Tue Sep 10 11:50:32 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQtObject no longer inherits QObject ?? In-Reply-To: <002501c2583b$f07ca310$6951800a@hsj.qc.ca> References: <002501c2583b$f07ca310$6951800a@hsj.qc.ca> Message-ID: <20020910095032.GA6860@sim.no> Philippe Debann? wrote: : Hello all, : : I just noticed that since SoQt 1.0.0 (I think), SoQtObject no longer : inherits QObject. This change was made 2002-06-17: > date: 2002/06/17 15:00:17; author: mortene; state: Exp; lines: +1 -9 > Reorganization, compile fixes, improved documentation. > Removes dependencies on Qt's ``moc''-tool for public header > files. : It seems to me that this is a significant design change; : what is the reason for it? SoQt itself obviously didn't need the functionality provided in QObject, and removing it cleaned up the design (and the files) quite a bit. : And if I want my own viewer subclass to have : signals and slots, must I now use multiple inheritance?, e.g. : : class MyViewer : public SoQtExaminerViewer, public QObject : { : Q_OBJECT : SOQT_OBJECT_HEADER(MyViewer , SoQtExaminerViewer); : (...) : }; The above should work, or you could swap the two around to get the QObject block first, not that it really should matter. : Also, is the inheritance of QObject somehow 'configure'able ? How do you mean? Are you thinking of a configure option for making SoQtObject be derived from QObject? No such option exists, and I'm not sure if such a thing ought to be configurable either. Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From colin at mve.com Tue Sep 10 12:12:18 2002 From: colin at mve.com (Colin Dunlop) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin virgin question on node extension. In-Reply-To: <002501c2583b$f07ca310$6951800a@hsj.qc.ca> Message-ID: <000e01c258b2$8be30850$0ec809c0@shetland> Hi, I'm not new to C++ and OpenGL in any way but quite new to Coin and OI and have a simple question. I'd quite like to extend the functionality of SoSwitch and looking at the source code it looks quite straightforward apart from the macros. Does anyone have a simple example or skeleton of an empty extended node with the macros all filled out with the idea to say override SoGLRenderAction in the subclass and say an extra float member variable - I notice that their seem to be macros to initialise member variables also - hmmmm. Please feel free to tell me to RTFM (Toolmaker/FAQ?) if this is covered elsewhere and I've missed it :-) Thought I'd ask before I waded in and "had a go". Colin. ps for the curious - I have a multithreaded app and I want to calculate/add/remove/render LOD safely and need a little locking around a few SoGroup/SoSwitch methods, as well as have app control over which LOD is active, as well as populate the not yet calculated LODs in the children of the SoSwitch with a temporary node. pss My main stumbling is what these do and if I need them in a derived node: From src/nodes/SoSwitch.cpp SO_NODE_SOURCE(SoSwitch); SO_NODE_INTERNAL_CONSTRUCTOR(SoSwitch); SO_NODE_ADD_FIELD(whichChild, (SO_SWITCH_NONE)); SO_NODE_INTERNAL_INIT_CLASS(SoSwitch); SO_ENABLE(SoGLRenderAction, SoSwitchElement); ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Tue Sep 10 13:57:12 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin virgin question on node extension. In-Reply-To: "Colin Dunlop"'s message of "Tue, 10 Sep 2002 11:12:18 +0100" References: <000e01c258b2$8be30850$0ec809c0@shetland> Message-ID: <517khu2h2f.fsf@nfs.trh.sim.no> Colin Dunlop writes: > I'd quite like to extend the functionality of SoSwitch and looking > at the source code it looks quite straightforward apart from the > macros. Does anyone have a simple example or skeleton of an empty > extended node with the macros all filled out [...] There's one in the SoNode class documentation, see . Other than that, we strongly recommend the ?Inventor Toolmaker? book. See chapter 2 "Creating a Node", and in particular the section "Creating a Group Node" (page 49 in my copy). All the macros are explained in detail there. > with the idea to say override SoGLRenderAction in the subclass [...] That is done by overriding the virtual method SoNode::GLRender(). The innards of the GLRender() methods aren't always trivial to implement, though. Read carefully the "Implementing Actions" and "Creating a Shape Node -> Rendering" in Toolmaker chapter 2. > and say an extra float member variable - I notice that their seem to > be macros to initialise member variables also - hmmmm. Member fields should be initialized by the macros, to make sure they are "registered" as part of the system for introspection, and for their nodes to automatically have proper export/import functionality. > pss My main stumbling is what these do and if I need them in a > derived node: From src/nodes/SoSwitch.cpp > > SO_NODE_SOURCE(SoSwitch); This one sets up the variables and methods for the type system for the class (ie so one can do SoSwitch::getClassTypeId() for instance) and implements a few methods needed by subclasses to access the fields of superclasses. > SO_NODE_INTERNAL_CONSTRUCTOR(SoSwitch); Note that this should be "SO_NODE_CONSTRUCTOR()" in non-native Coin (extension) classes. The "SO_*_INTERNAL_*()" macros are unavailable for the application programmer. It does initializations of the type system and field lists. > SO_NODE_ADD_FIELD(whichChild, (SO_SWITCH_NONE)); Needed for each public field. Connects the field to it's node owner and sets it up with a default value. > SO_NODE_INTERNAL_INIT_CLASS(SoSwitch); Should be "SO_NODE_INIT_CLASS()" in your case. Note that the public version also needs some more arguments, consult the Toolmaker again. > SO_ENABLE(SoGLRenderAction, SoSwitchElement); It is unlikely that you need to use this macro, unless you want your new node to "communicate" with other extension nodes in the scenegraph through the state-stack. Anyway, this is also explained in the Toolmaker's chapter 2. Don't hesitate to forward further questions you might have. Extending the library with new nodes is not entirely trivial, so we expect support inquiries for those who venture in that direction. :-) Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Tue Sep 10 15:05:53 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Problem with reimplemented processSoEvent() and picking Nurbs In-Reply-To: Philippe =?iso-8859-1?q?Debann=E9's?= message of "Fri, 6 Sep 2002 21:45:50 -0400" References: <009001c25610$4e58c0a0$6951800a@hsj.qc.ca> Message-ID: <51u1kyc7v2.fsf@nfs.trh.sim.no> Philippe Debann? writes: > [...] This provokes the following error (in Debug configuration) > ---------------------------------- > File: i386\chkesp.c > Line: 42 > Value of ESP not properly saved accross a function call. (...) > ---------------------------------- This error message basically spells heap or stack corruption, which of course is very serious. There can be many different reasons for this problem: a) MSVC++ has generated buggy code. (See , last Q&A on the page.) b) There is a mismatch in the setup of exception-handling in SuperGLU versus Coin. (See .) c) Our NURBS-callbacks from Coin into SuperGLU are not set up correctly with regard to the number or the type of the arguments. d) We're using SuperGLU with a different calling convention than what it was compiled with. a) is unlikely to be the cause of the problem in this case, but there is actually a bug in MSVC++ pre-SP2 that results in these kinds of problems. To find out which one of b), c) or d) it is (if any), further investigation is needed. > Has anyone else encountered this problem? It's fairly common, as it's a check MSVC++ inserts into all function calling code in Debug mode. We've had one other person report the same problem as you do, ie nurbs-related code in Coin resulting in this. We also have a bug report about a /crash/ in SuperGLU that sounds like it _could_ be related to this. We will investigate. > As far as I can tell it only happens with nurbs shapes, so I wonder > if it's related to the superglu embedded in Coin. That sounds, likely, yes. > But then, why does it only happen when I derive my own viewer class? That is indeed very peculiar. Are you sure the picking actually happens when you are using one of the built-in viewer classes? We would very much appreciate a minimal, stand-alone example that reproduces the bug on your system. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Tue Sep 10 15:13:16 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Problem with reimplemented processSoEvent() and picking Nurbs In-Reply-To: Morten Eriksen's message of "10 Sep 2002 15:05:53 +0200" References: <009001c25610$4e58c0a0$6951800a@hsj.qc.ca> <51u1kyc7v2.fsf@nfs.trh.sim.no> Message-ID: <51sn0iugwj.fsf@nfs.trh.sim.no> Morten Eriksen writes: > Philippe Debann? writes: > > > [...] This provokes the following error (in Debug configuration) > > ---------------------------------- > > File: i386\chkesp.c > > Line: 42 > > Value of ESP not properly saved accross a function call. (...) > > ---------------------------------- > > This error message basically spells heap or stack corruption, which > of course is very serious. There can be many different reasons for > this problem: [...] I forgot to mention one other possibility; SGI's GLU-code might be doing something wrong with setjmp / longjmp. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Craig.McIntyre at Tenix.com Wed Sep 11 01:24:23 2002 From: Craig.McIntyre at Tenix.com (MCINTYRE Craig) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQtObject no longer inherits QObject ?? Message-ID: <200209102324.JAA15234@sprint.tenix.com> > : I just noticed that since SoQt 1.0.0 (I think), SoQtObject no longer > : inherits QObject. > > : And if I want my own viewer subclass to have > : signals and slots, must I now use multiple inheritance?, e.g. > : > : class MyViewer : public SoQtExaminerViewer, public QObject > : { > : Q_OBJECT > : SOQT_OBJECT_HEADER(MyViewer , SoQtExaminerViewer); > : (...) > : }; > > The above should work, or you could swap the two around to > get the QObject > block first, not that it really should matter. If you are inheriting from multiple classes the first class *must* be a QObject otherwise moc gets confused. See http://doc.trolltech.com/3.0/moc.html and look under the Limitations section. Cheers. ---- Craig McIntyre Software Engineer Simulation Group Electronic Systems Division Tenix Defence Pty Ltd ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From pdebanne at justine.umontreal.ca Wed Sep 11 05:01:50 2002 From: pdebanne at justine.umontreal.ca (=?iso-8859-1?Q?Philippe_Debann=E9?=) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Problem with reimplemented processSoEvent() and picking Nurbs References: <009001c25610$4e58c0a0$6951800a@hsj.qc.ca> <51u1kyc7v2.fsf@nfs.trh.sim.no> Message-ID: <001201c2593f$95a9cc60$6951800a@hsj.qc.ca> Thanks Morten. I finally recompiled Coin v.1.0.2 and SoQt v.0.10.0 myself (under Cygwin), and this eliminates the problem. However this integrates the standard GLU provided with MSVC, which is not as "smart" as SuperGLU but at least doesn't crash my application!! I have yet to download the SuperGLU source and try using it (Is ftp.coin3d.org/pub/coin/misc/ the right place to get it?) As for your reply, yes definitely in the precompiled Win32 version something gets corrupted in the function calling between my app, MSVC, SoQt, Coin and SuperGLU. > Are you sure the picking actually happens when you are using one of the > built-in viewer classes? I'm pretty sure, given that the viewer is in interact mode (events passed to scene graph). I discovered another condition required to create the problem though: the object must be under a SoSelection node. > We would very much appreciate a minimal, stand-alone example that > reproduces the bug on your system. Attached is a zip containing an MSVC project that reproduces the problem on my system. (The proto.bat and Nurbs.pro allow to regenerate the .dsp with qmake). The program is adapted from Inventor Mentor ex. 8.1. Let me know if you get the same bug. Regards, Phil D. -------------- next part -------------- A non-text attachment was scrubbed... Name: Nurbs.zip Type: application/x-zip-compressed Size: 5584 bytes Desc: not available Url : /pipermail/coin-discuss/attachments/20020910/dc34706d/Nurbs.bin From larsa at sim.no Wed Sep 11 10:12:41 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQtObject no longer inherits QObject ?? In-Reply-To: <200209102324.JAA15234@sprint.tenix.com> References: <200209102324.JAA15234@sprint.tenix.com> Message-ID: <20020911081241.GA14953@sim.no> MCINTYRE Craig wrote: : : > : And if I want my own viewer subclass to have : > : signals and slots, must I now use multiple inheritance?, e.g. : > : : > : class MyViewer : public SoQtExaminerViewer, public QObject : > : { : > : > The above should work, or you could swap the two around to : > get the QObject block first, not that it really should matter. : : : If you are inheriting from multiple classes the first class *must* be a : QObject otherwise moc gets confused. Ah, I was thinking compiler-wise. What subset of C++ moc understands is of course a totally different issue :) Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From colin at mve.com Wed Sep 11 10:57:18 2002 From: colin at mve.com (Colin Dunlop) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin virgin question on node extension. In-Reply-To: <517khu2h2f.fsf@nfs.trh.sim.no> Message-ID: <000a01c25971$3c5512a0$0ec809c0@shetland> Morten, thanks for your detailed and in depth reply - appreciated! I think I have enough now to go on after reading the doxygen and your notes. The drones at Amazon are dispatching the Inventor Toolmaker right now. Thanks again, Colin. > -----Original Message----- > From: Morten Eriksen [mailto:mortene@sim.no] > Sent: 10 September 2002 12:57 > To: colin@mve.com > Cc: coin-discuss@sim.no > Subject: Re: [coin-discuss] Coin virgin question on node extension. > > > Colin Dunlop writes: > > > I'd quite like to extend the functionality of SoSwitch and looking > > at the source code it looks quite straightforward apart from the > > macros. Does anyone have a simple example or skeleton of an empty > > extended node with the macros all filled out [...] > > There's one in the SoNode class documentation, see > . > > Other than that, we strongly recommend the ?Inventor Toolmaker? > book. See chapter 2 "Creating a Node", and in particular the section > "Creating a Group Node" (page 49 in my copy). > > All the macros are explained in detail there. > > > with the idea to say override SoGLRenderAction in the subclass [...] > > That is done by overriding the virtual method SoNode::GLRender(). The > innards of the GLRender() methods aren't always trivial to implement, > though. Read carefully the "Implementing Actions" and "Creating a > Shape Node -> Rendering" in Toolmaker chapter 2. > > > and say an extra float member variable - I notice that their seem to > > be macros to initialise member variables also - hmmmm. > > Member fields should be initialized by the macros, to make sure they > are "registered" as part of the system for introspection, and for > their nodes to automatically have proper export/import functionality. > > > pss My main stumbling is what these do and if I need them in a > > derived node: From src/nodes/SoSwitch.cpp > > > > SO_NODE_SOURCE(SoSwitch); > > This one sets up the variables and methods for the type system for the > class (ie so one can do SoSwitch::getClassTypeId() for instance) and > implements a few methods needed by subclasses to access the fields of > superclasses. > > > SO_NODE_INTERNAL_CONSTRUCTOR(SoSwitch); > > Note that this should be "SO_NODE_CONSTRUCTOR()" in non-native Coin > (extension) classes. The "SO_*_INTERNAL_*()" macros are unavailable > for the application programmer. > > It does initializations of the type system and field lists. > > > SO_NODE_ADD_FIELD(whichChild, (SO_SWITCH_NONE)); > > Needed for each public field. Connects the field to it's node owner > and sets it up with a default value. > > > SO_NODE_INTERNAL_INIT_CLASS(SoSwitch); > > Should be "SO_NODE_INIT_CLASS()" in your case. Note that the public > version also needs some more arguments, consult the Toolmaker again. > > > SO_ENABLE(SoGLRenderAction, SoSwitchElement); > > It is unlikely that you need to use this macro, unless you want your > new node to "communicate" with other extension nodes in the scenegraph > through the state-stack. Anyway, this is also explained in the > Toolmaker's chapter 2. > > Don't hesitate to forward further questions you might have. Extending > the library with new nodes is not entirely trivial, so we expect > support inquiries for those who venture in that direction. :-) > > Regards, > Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Wed Sep 11 11:30:07 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin virgin question on node extension. In-Reply-To: "Colin Dunlop"'s message of "Wed, 11 Sep 2002 09:57:18 +0100" References: <000a01c25971$3c5512a0$0ec809c0@shetland> Message-ID: <51wupsswkg.fsf@nfs.trh.sim.no> "Colin Dunlop" writes: > The drones at Amazon are dispatching the Inventor Toolmaker right > now. The book is also available from SGI's online library of publications as HTML, at no cost. Load , use "toolmaker" for the keyword search, then click "download" at the top item from the search. It's nice to have a copy on dead trees aswell, though. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Anderson_Mark_D at cat.com Thu Sep 12 21:31:50 2002 From: Anderson_Mark_D at cat.com (Mark D. Anderson) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Changing Mouse Button Definitions in ExaminerViewer Message-ID: Hello all, I am wondering if there is an easy way to re-assign the mouse button actions in the Examiner Viewer. Do I just have to override the processSoEvent() method in my own inherited ExaminerViewer? Or is there an easier way, like re-defining the Button1 / Button2 etc. masks (similar to a post a couple months back regarding SoQt having different mouse button masks)? We would like to provide an easy way for users to switch between the default Inventor paradigm and, say, Pro/Engineer or IDEAS layouts, so this would be more than just the button mask (the ctrl and alt modifiers have to be handled differently, as well). It seems that there is an awful lot going on in processSoEvent, so I'd like to avoid simply copying all that code for some event re-mappings, if possible (maybe just re-map/alter the events and pass them up the chain; is this 'legal'??) Thanks for any advice, Mark Anderson ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Thu Sep 12 22:40:40 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] unpredictable coin3d.org availability on friday (++?) Message-ID: <20020912204040.GA20197@sim.no> Hi folks, Systems in Motion is moving the Trondheim offices to a new location tomorrow / this weekend, including our Internet name, mail, web, cvs, and ftp servers. This means that more or less all Internet services hosted at coin3d.org/sim.no will be down for a period of time I'm not willing to predict the extent of - ok, something between 20 minutes and half a week ;) What I'm saying is - you can update your repositories and fetch those snapshots now, or you will have to wait until we are back up again. Sorry for any inconvenience this may cause you... Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From pdebanne at justine.umontreal.ca Fri Sep 13 00:00:37 2002 From: pdebanne at justine.umontreal.ca (=?iso-8859-1?Q?Philippe_Debann=E9?=) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Changing Mouse Button Definitions in ExaminerViewer References: Message-ID: <009301c25aa7$d67f9940$6951800a@hsj.qc.ca> Hi again, > However, I'm stuck with the problem of mouse cursor representation: I need > to change its behaviour in the same way, but all related members are private > to ExaminerViewer (enum ViewerMode, setMode(), setCursorRepresentation > ()). Actually I just found the answer and it's quite simple. Just call: setComponentCursor ( const SoQtCursor & cursor ) which is nice and public :->. See the 'SoQtCursor.h' file for details. (Doesn't seem to be included in the generated doc.) Philippe D. ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From pdebanne at justine.umontreal.ca Fri Sep 13 00:01:18 2002 From: pdebanne at justine.umontreal.ca (=?iso-8859-1?Q?Philippe_Debann=E9?=) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Changing Mouse Button Definitions in ExaminerViewer Message-ID: <009d01c25aa7$ef1738f0$6951800a@hsj.qc.ca> Hello Mark, > It seems that there is an awful lot going on in processSoEvent, so I'd > like to avoid simply copying all that code for some event re-mappings, > if possible (maybe just re-map/alter the events and pass them up the > chain; is this 'legal'??) That is what I've done in my subclass. To change the ExaminerViewer's pan/zoom/rotate mode selection behaviour, I generate "fake" mouse-button-press/release events and pass them to the inherited method. E.g. to enter zoom mode, ExaminerViewer expects mouse left-button+middle button presses (that's one way of entering zoom). This works, and avoids copy-pasting a lot of internal code from ExaminerViewer, which is what I used to have when I inherited FullViewer instead. However, I'm stuck with the problem of mouse cursor representation: I need to change its behaviour in the same way, but all related members are private to ExaminerViewer (enum ViewerMode, setMode(), setCursorRepresentation()). So I wouldn't mind finding a better solution. I'm still working with a SoQt beta version and the class structure has changed in the newer SoQt, but I believe the problem of private members remains. Regards, Philippe Debann? ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 13 08:57:07 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Changing Mouse Button Definitions in ExaminerViewer In-Reply-To: Philippe =?iso-8859-1?q?Debann=E9's?= message of "Thu, 12 Sep 2002 18:00:37 -0400" References: <009301c25aa7$d67f9940$6951800a@hsj.qc.ca> Message-ID: <51znumv0l8.fsf@nfs.trh.sim.no> Philippe Debann? writes: > ([SoQtCursor doesn't] seem to be included in the generated doc.) Oops, left out by mistake. I'm fixing it now. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 13 09:16:44 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Changing Mouse Button Definitions in ExaminerViewer In-Reply-To: "Mark D. Anderson"'s message of "Thu, 12 Sep 2002 14:31:50 -0500" References: Message-ID: <51vg5auzoj.fsf@nfs.trh.sim.no> "Mark D. Anderson" writes: > I am wondering if there is an easy way to re-assign the mouse button > actions in the Examiner Viewer. Do I just have to override the > processSoEvent() method in my own inherited ExaminerViewer? As Philippe said and you suggests yourself, you can do it by just overriding processSoEvent() and then pass in your own event stream to the superclass. But this is a bit of a hack (although pretty safe), and you're not the first to ask how to do this (see the file SoQt/src/Inventor/Qt/common/docs/api-wish-list.txt from the SoQt development repository), so we should really extend the API to have a proper interface. I'm not sure what the design of that API should be like, though. Any suggestions would be appreciated. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From gatien.mellion at criltechnology.com Fri Sep 13 15:12:49 2002 From: gatien.mellion at criltechnology.com (MELLION Gatien) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQT Message-ID: <1D75B5ABA724EE47BE16201EBA060A8F2C9DE5@belzebuth.ouest.criltechnology.net> hi, I'm trying SoQt under SGI IRIX 6.5 / Qt 3.0, When compiling and integrating with my code, I have some problems... Does s.o. has a solution for that ? : ---------- CFenVueLibre.cpp ---------- CC -c -n32 -g -D_DEBUG -DDEBUG -woff all -I../CBasique -I/mosar/users/gme/RESU3D/qt-unix/include -I../ORB -I/mosar/users/gme/RESU3D/OOC/include -I../InterfaceCORBA -I../CQtWidget -I../CQtVisu2D -I../qwt -I../LibIHM -I../LibResu3D -I../CNetCdf35 -I../LibLectureBDD -I../CVisu3D -I../CSound -I../CGeometrie -I. -I../SoQt -DHAVE_CONFIG_H -DSOQT_DEBUG=1 -DSOQT_INTERNAL CFenVueLibre.cpp -o CFenVueLibre.o; cc-1040 CC: ERROR File = ../SoQt/SoQtGLWidget.h, Line = 47 An identifier is expected. SO_GL_RGB = 0x01, SO_GLX_RGB = SO_GL_RGB, ^ cc-1040 CC: ERROR File = ../SoQt/SoQtGLWidget.h, Line = 48 An identifier is expected. SO_GL_DOUBLE = 0x02, SO_GLX_DOUBLE = SO_GL_DOUBLE, ^ cc-1040 CC: ERROR File = ../SoQt/SoQtGLWidget.h, Line = 49 An identifier is expected. SO_GL_ZBUFFER = 0x04, SO_GLX_ZBUFFER = SO_GL_ZBUFFER, ^ cc-1040 CC: ERROR File = ../SoQt/SoQtGLWidget.h, Line = 50 An identifier is expected. SO_GL_OVERLAY = 0x08, SO_GLX_OVERLAY = SO_GL_OVERLAY, ^ cc-1040 CC: ERROR File = ../SoQt/So ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Fri Sep 13 15:21:22 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQT In-Reply-To: <1D75B5ABA724EE47BE16201EBA060A8F2C9DE5@belzebuth.ouest.criltechnology.net> References: <1D75B5ABA724EE47BE16201EBA060A8F2C9DE5@belzebuth.ouest.criltechnology.net> Message-ID: <20020913132122.GA26709@sim.no> MELLION Gatien wrote: : : hi, : : I'm trying SoQt under SGI IRIX 6.5 / Qt 3.0, : : When compiling and integrating with my code, I have some problems... : Does s.o. has a solution for that ? : : : ---------- CFenVueLibre.cpp ---------- : CC -c -n32 -g -D_DEBUG -DDEBUG -woff all -I../CBasique -I/mosar/users/gme/RESU3D/qt-unix/include -I../ORB -I/mosar/users/gme/RESU3D/OOC/include -I../InterfaceCORBA -I../CQtWidget -I../CQtVisu2D -I../qwt -I../LibIHM -I../LibResu3D -I../CNetCdf35 -I../LibLectureBDD -I../CVisu3D -I../CSound -I../CGeometrie -I. -I../SoQt -DHAVE_CONFIG_H -DSOQT_DEBUG=1 -DSOQT_INTERNAL CFenVueLibre.cpp -o CFenVueLibre.o; : cc-1040 CC: ERROR File = ../SoQt/SoQtGLWidget.h, Line = 47 : An identifier is expected. : : SO_GL_RGB = 0x01, SO_GLX_RGB = SO_GL_RGB, : ^ The most likely reason for this is that SO_GLX_RGB is already set up as a define, something for instance InventorXt from SGI does. Does CFenVueLibre.cpp in any way include any fies from Inventor/Xt/? Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From gatien.mellion at criltechnology.com Fri Sep 13 16:35:25 2002 From: gatien.mellion at criltechnology.com (MELLION Gatien) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQT Message-ID: <1D75B5ABA724EE47BE16201EBA060A8F2C9DE7@belzebuth.ouest.criltechnology.net> I succeed in compiling and linking my application with SoQt. when I launch my program, I got the following message : Inventor warning in SoQt::getShellWidget(): Called with NULL pointer. Segmentation fault (core dumped) At first, I change SoQt::init(""); with SoQt::init(pMainWidow); //QWidget* but I have still the same message. When I look at my initialisation of the component, it look good : m_pViewer = new SoQtExaminerViewer(parent); So could s.o. see the trouble? Gatien ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Fri Sep 13 17:06:12 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQT In-Reply-To: <1D75B5ABA724EE47BE16201EBA060A8F2C9DE7@belzebuth.ouest.criltechnology.net> References: <1D75B5ABA724EE47BE16201EBA060A8F2C9DE7@belzebuth.ouest.criltechnology.net> Message-ID: <20020913150612.GA30114@sim.no> MELLION Gatien wrote: : I succeed in compiling and linking my application with SoQt. : : when I launch my program, I got the following message : : : Inventor warning in SoQt::getShellWidget(): Called with NULL pointer. : Segmentation fault (core dumped) If you can produce a stack trace from the core dump, it would be helpful. : At first, I change : : SoQt::init(""); : : with : : SoQt::init(pMainWidow); //QWidget* : : but I have still the same message. : : : When I look at my initialisation of the component, it look good : : : m_pViewer = new SoQtExaminerViewer(parent); : : : So could s.o. see the trouble? Hard to say. What is "parent"? Are you trying to embed the viewer in a custom window, or are you just interested in a stand-alone Examiner viewer? In the latter case, parent should either be "NULL" (default) or the QWidget returned from SoQt::init(). Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From gatien.mellion at criltechnology.com Fri Sep 13 17:14:44 2002 From: gatien.mellion at criltechnology.com (MELLION Gatien) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoQT Message-ID: <1D75B5ABA724EE47BE16201EBA060A8F2C9DEA@belzebuth.ouest.criltechnology.net> : : : So could s.o. see the trouble? Hard to say. What is "parent"? Are you trying to embed the viewer in a custom window, or are you just interested in a stand-alone Examiner viewer? In the latter case, parent should either be "NULL" (default) or the QWidget returned from SoQt::init(). Lars J >> At first, I made an example : int main(int argc, char ** argv) { QApplication app(argc, argv); QWidget * parent = new QWidget; app.setMainWidget(parent); SoQt::init(""); SoInput in; in.openFile(argv[1]); SoSeparator * root = SoDB::readAll(&in); root->ref(); SoQtExaminerViewer * viewer = new SoQtExaminerViewer(parent); viewer->setSceneGraph(root); viewer->show(); app.exec(); return 0; } >> It works fine... :) >> >> Then I wanted to embed the ExaminerViewer in a QFrame of my application (which is a big application). And that's here I got this error message : Inventor warning in SoQt::getShellWidget(): Called with NULL pointer. >> I thought it's coming from this line, but I'm not sure : m_pViewer = new SoXtExaminerViewer(parent); >> parent is the QFrame of my application. I do this allocation in the constructor of my window class. >> well... I know it's not really concrete. Just if you have an idea... Gatien ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From kyrah at sim.no Mon Sep 16 12:13:40 2002 From: kyrah at sim.no (Karin Kosina) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Mac OS 10.2 support Message-ID: <20020916101340.GH2807@sim.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Since there have been a number of questions concerning Coin and Mac OS 10.2, I thought I would summarize things here. First of all, yes, we do support Mac OS 10.2. That's the good news. The bad news is that SoQt won't work on Mac OS 10.2 until Qt supports Jaguar, which will probably (hopefully?) be in the Qt/Mac 3.1beta2. Note that if you are upgrading to Mac OS 10.2, you must recompile your Coin library. This is due to the fact that the developer tools for Mac OS 10.2 are based on gcc.3.1, as opposed to gcc-2.95 in 10.1. These two compilers are not ABI compatible, so you have to rebuild all your C++ libs. If you decide to build Coin from the source code, please cvs update or download the latest snapshot (after 20020915). Note that there are several bugs in the developer tools that came with the original Mac OS 10.2 CDs, so you should install the update provided by Apple ("August2002DevToolsUpdate") first. A precompiled binary for the Coin framework on Mac OS 10.2 can be found on our ftp server[0]. If you try to build a project using Coin in Project Builder, you might get an error message about __Znwm being undefined. What causes this, and how to get rid of it, is explained in the README.MAC file in the Coin-1 source directory. Please feel free if you have any comments or problems. Have fun taming the Jaguar :) Regards, #!/kyrah [0] ftp://ftp.coin3d.org/pub/coin/bin/macosx/Coin-1.0.2_Mac-OS-10.2.sit - -- Karin Kosina (vka kyrah) http://kyrah.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE9ha667vvdOh/igesRAtwOAKCAbTrO5jzDZFmGAnD46BZbDc5X3QCfTdPC M/NoVG/GCzUGKnYirkW8v5E= =iBge -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Mon Sep 16 16:49:09 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin 1.0.3 Released Message-ID: <20020916144909.GA32155@sim.no> Coin 1.0.3 Released =================== Systems in Motion is proud to finally release v1.0.3 of the Coin 3D graphics library. Coin 1.0.3 is a patchlevel release. Patchlevel releases contains bugfixes, optimizations, documentation improvements, and configure and build setup fixes. It does not extend the library API beyond the previous release. NEWS File Excerpt: ------------------ * SoWWWAnchor implementation * SoConcatenate engine optimization * Mac OS X: implementation of the SoOffscreenRenderer * the usual optimizations, bugfixes, documentation updates, build-setup fixes See also the file RELNOTES, and if you want the really gory details, the ChangeLog file. Download Information: --------------------- This message may be posted before the given files are available. In that case, try again at a later time. Source Code by FTP: ftp://ftp.coin3d.org/pub/coin/src/Coin-1.0.3.tar.gz Precompiled releases are not ready now, but will appear after they have been properly built. May take a couple of days on account that out internal network is not 100% back up yet after moving offices. Anyways, they will appear at these locations: Precompiled for Linux (i386): Debian (Woody) apt-get: $ apt-get install libcoin20-dev Precompiled for MS Windows: ftp://ftp.coin3d.org/pub/coin/bin/win32/coin-v1.0.3-install.exe Precompiled for Mac OS X: ftp://ftp.coin3d.org/pub/coin/bin/macosx/Coin-1.0.3.sit Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Jan-Harald.Fredriksen at idi.ntnu.no Mon Sep 16 17:28:48 2002 From: Jan-Harald.Fredriksen at idi.ntnu.no (Jan-Harald Fredriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin for handhelds Message-ID: Would coin be suited for handheld platforms ? (given that an openGL implementation is available) If so, how much work would porting it require? (the GUI bindings will not be necessary) Regards, Jan-Harald Fredriksen ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From aclemens at xs4all.nl Mon Sep 16 17:37:58 2002 From: aclemens at xs4all.nl (Arthur Clemens) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin 1.0.3 Released In-Reply-To: <20020916144909.GA32155@sim.no> Message-ID: <46D496E7-C98A-11D6-9B34-00039366A36E@xs4all.nl> 1.0.3 for Mac OS X seems to be missing.... Arthur Clemens On maandag, sep 16, 2002, at 16:49 Europe/Amsterdam, Lars J. Aas wrote: > > Coin 1.0.3 Released > =================== > > Systems in Motion is proud to finally release v1.0.3 of the Coin 3D > graphics library. Coin 1.0.3 is a patchlevel release. Patchlevel > releases contains bugfixes, optimizations, documentation improvements, > and configure and build setup fixes. It does not extend the library > API beyond the previous release. > > > NEWS File Excerpt: > ------------------ > > * SoWWWAnchor implementation > * SoConcatenate engine optimization > * Mac OS X: implementation of the SoOffscreenRenderer > * the usual optimizations, bugfixes, documentation updates, > build-setup fixes > > See also the file RELNOTES, and if you want the really gory details, > the ChangeLog file. > > > Download Information: > --------------------- > > This message may be posted before the given files are available. > In that case, try again at a later time. > > Source Code by FTP: > ftp://ftp.coin3d.org/pub/coin/src/Coin-1.0.3.tar.gz > > Precompiled releases are not ready now, but will appear after they > have been properly built. May take a couple of days on account that > out internal network is not 100% back up yet after moving offices. > Anyways, they will appear at these locations: > > Precompiled for Linux (i386): > Debian (Woody) apt-get: > $ apt-get install libcoin20-dev > > Precompiled for MS Windows: > ftp://ftp.coin3d.org/pub/coin/bin/win32/coin-v1.0.3-install.exe > > Precompiled for Mac OS X: > ftp://ftp.coin3d.org/pub/coin/bin/macosx/Coin-1.0.3.sit > > Lars J > > ----------------------------------------------------------------------- > ------- > To unsubscribe from coin-discuss, email with the > subject > "unsubscribe coin-discuss". For general help, use "help" as the > subject. > See http://www.coin3d.org/ for additional information. > > ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Mon Sep 16 17:48:38 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin 1.0.3 Released In-Reply-To: <46D496E7-C98A-11D6-9B34-00039366A36E@xs4all.nl> References: <20020916144909.GA32155@sim.no> <46D496E7-C98A-11D6-9B34-00039366A36E@xs4all.nl> Message-ID: <20020916154838.GA1653@sim.no> Arthur Clemens wrote: : 1.0.3 for Mac OS X seems to be missing.... Only the source archive is ready yet, which is the same for all platforms. Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From kyrah at sim.no Mon Sep 16 18:32:33 2002 From: kyrah at sim.no (Karin Kosina) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin 1.0.3 Released In-Reply-To: <20020916144909.GA32155@sim.no> References: <20020916144909.GA32155@sim.no> Message-ID: <20020916163233.GD9367@sim.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +----- Lars J. Aas -- Mon, Sep 16, 2002 at 04:49:09PM +0200 ---- | Precompiled for Mac OS X: | ftp://ftp.coin3d.org/pub/coin/bin/macosx/Coin-1.0.3.sit Actually, there are two versions -- one for Mac OS 10.1, and one for Mac OS 10.2 (since those two are not binary compatible). ftp://ftp.coin3d.org/pub/coin/bin/macosx/Coin-1.0.3_Mac-OS-10.2.sit (available in 10 minutes ;)) ftp://ftp.coin3d.org/pub/coin/bin/macosx/Coin-1.0.3_Mac-OS-10.1.sit (coming soon) Regards, #!/kyrah - -- Karin Kosina (vka kyrah) http://kyrah.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE9hgee7vvdOh/igesRAq5RAJwM+b22SmB08YsS9kdEoW0CDaaC0ACfYT35 IsBGBwy4KTnTpAuqtyfqoeQ= =nTkZ -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Mon Sep 16 20:58:43 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] Coin for handhelds In-Reply-To: Jan-Harald Fredriksen's message of "Mon, 16 Sep 2002 17:28:48 +0200 (MEST)" References: Message-ID: <51ptvd69ss.fsf@nfs.trh.sim.no> Jan-Harald Fredriksen writes: > Would coin be suited for handheld platforms ? Coin is a pretty huge library measured in size of object-code (I haven't checked in a while, but last figure I remember for a release ix86 build was just above 2MB), so porting it would probably require either that the platform in question has a decent amount of storage available, or that one made the effort to slim down Coin. > (given that an openGL implementation is available) If so, how much > work would porting it require? If the platform is "fat" enough resource-wise, I would guess it should take very little effort. The only real dependencies Coin has is a) OpenGL, and b) a half-way decent C++ compiler. If slimming down the library is necessary to make it fit within the usually limited resources available on a handheld platform, it would take some more effort. Perhaps not *that* much, given that there are large parts of Coin that could be taken out without really affecting the "core" parts: all the VRML97 nodes, node kits, dragger classes, manipulators and engines. That should quickly bring down the size of object-code a _lot_. Many node classes and actions could also be taken out, for further shrinkage. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From uxm165t at tninet.se Wed Sep 18 21:00:20 2002 From: uxm165t at tninet.se (Linus Akerlund) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoGtk and gtk2? Message-ID: <20020918190020.GA14112@roky.student.uu.se> Hello, Are there any plans to port SoGtk to gtk2? Linus ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From vinh2 at email.arc.nasa.gov Thu Sep 19 01:29:12 2002 From: vinh2 at email.arc.nasa.gov (Vinh To) Date: Sat Jul 30 15:53:40 2005 Subject: [coin-discuss] SoGLLineWidthElement error using JackManip Message-ID: <005101c25f6b$3226d3e0$6144e88f@LONESTARR> I'm getting an SoGLLineWidthElement::updategl() error saying that I'm out of range when I try to display the following file: JackManip { translation 0 0 0 rotation 0 0 1 0 scaleFactor 1 1 1 scaleOrientation 0 0 1 0 center 0 0 0 } Separator { Material { ambientColor 0.0 1.0 0.0 emissiveColor 0.0 0.5 0 shininess 0.4 } DrawStyle { lineWidth 1 } Sphere { radius 0.05 } } I'm just using an SoWinExaminerViewer to display it. When I opened the same file using TGS, I don't get the error. I have tried with coin-1.0.2 and coin-1.0.3. Is this a bug and is there a simple workaround for it? Thanks, Vinh -------------- next part -------------- An HTML attachment was scrubbed... URL: /pipermail/coin-discuss/attachments/20020918/6dee5216/attachment.html From aclemens at xs4all.nl Thu Sep 19 11:57:17 2002 From: aclemens at xs4all.nl (Arthur Clemens) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] compile errors on Mac OS X 10.2 In-Reply-To: <005101c25f6b$3226d3e0$6144e88f@LONESTARR> Message-ID: <2E0A3CFC-CBB6-11D6-89C5-00039366A36E@xs4all.nl> Am I the only one having problems running Coin on OS X 10.2? I tried Cocoa-in-a-Nutshell just for testing, and get a lot of errors, that seem to indicate I am missing (or the compiler cannot find) some essential libraries: Linking /Users/arthurclemens/Desktop/downloads/Coin-In-A-Cocoa-Nutshell/build/ Coin-In-A-Cocoa-Nutshell.app/Contents/MacOS/Coin-In-A-Cocoa-Nutshell (1 error, 5 warnings) ld: warning can't open dynamic library: /usr/local/lib/libsimage.20.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: warning can't open dynamic library: libtiff.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: warning can't open dynamic library: libpng.1.2.0.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: warning can't open dynamic library: /usr/local/lib/libjpeg.62.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: warning can't open dynamic library: /usr/local/lib/libungif.4.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _simage_check_save_supported _simage_check_supported _simage_free_image _simage_get_last_error _simage_get_num_savers _simage_get_saver_description _simage_get_saver_extensions _simage_get_saver_fullname _simage_get_saver_handle _simage_next_power_of_two _simage_read_image _simage_resize _simage_save_image _simage_version Arthur Clemens -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1723 bytes Desc: not available Url : /pipermail/coin-discuss/attachments/20020919/9edd7934/attachment.bin From Jeremy.Walton at nag.co.uk Thu Sep 19 16:28:48 2002 From: Jeremy.Walton at nag.co.uk (Jeremy Walton) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] Re: Popupmenu Message-ID: Hi all, I, too, am trying to replace the popup menu with one of my own devising, although I'm trying it for SoWinExaminerViewer rather than SoQtExaminerViewer. I've followed Morten and Peter's advice and tried to override the setPopupMenu method of SoWinFullViewer in my own viewer subclass, by doing something like: virtual void buildPopupMenu(void) { printf("my buildPopupMenu()\n") ; this->prefmenu = this->common->setupStandardPopupMenu() ; this->prefmenu->setMenuTitle(ROOT_MENU, "Hello World!!!") ; this->prefmenu->newMenu("rootmenu", ROOT_MENU) ; } but have run into trouble because prefmenu is a private member of SoWinFullViewer, and I can't access it. This problem doesn't arise for SoQt*, where prefmenu isn't a private member of SoQtFullViewer (there's also a handy class called SoQtPopupMenu, which doesn't appear to have a counterpart in SoWin*). Does anyone have any suggestions for other things to try here? Has anyone already done this for SoWin*? Should I give up on SoWin and port the whole thing to SoQt? Any help gratefully received - many thanks. Cheers, Jeremy _____________________________________________________________________ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service. ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From kyrah at sim.no Fri Sep 20 12:29:57 2002 From: kyrah at sim.no (Karin Kosina) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] compile errors on Mac OS X 10.2 In-Reply-To: <2E0A3CFC-CBB6-11D6-89C5-00039366A36E@xs4all.nl> References: <005101c25f6b$3226d3e0$6144e88f@LONESTARR> <2E0A3CFC-CBB6-11D6-89C5-00039366A36E@xs4all.nl> Message-ID: <20020920102957.GB571@sim.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +----- Arthur Clemens -- Thu, Sep 19, 2002 at 11:57:17AM +0200 ---- | Am I the only one having problems running Coin on OS X 10.2? | I tried Cocoa-in-a-Nutshell just for testing, and get a lot of errors, | that seem to indicate I am missing (or the compiler cannot find) some | essential libraries: | [simage-linking errors snipped] Strange. Please specify: Did you build Coin yourself, or install the binary version? Coin-1.0.2 or Coin-1.0.3? 10.2 or 10.2.1? Regards, #!/kyrah - -- Karin Kosina (vka kyrah) http://kyrah.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE9iuCn7vvdOh/igesRAl8eAJ0d94auBqNpM3lrKjSfyOaWm97aWQCfQs9T KQmBWonLSwdOiMTRAgYEQ5E= =qG/e -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From aclemens at xs4all.nl Fri Sep 20 13:36:07 2002 From: aclemens at xs4all.nl (Arthur Clemens) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] compile errors on Mac OS X 10.2 In-Reply-To: <20020920102957.GB571@sim.no> Message-ID: <26FC2084-CC8D-11D6-87D6-00039366A36E@xs4all.nl> > > Please specify: > Did you build Coin yourself, or install the binary version? Coin-1.0.2 > or Coin-1.0.3? 10.2 or 10.2.1? I downloaded and installed the binary version of Coin-1.0.3. My system is 10.2.1. Arthur ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 20 15:43:24 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] Re: Popupmenu In-Reply-To: Jeremy Walton's message of "Thu, 19 Sep 2002 15:28:48 +0100" References: Message-ID: <51u1kkixoj.fsf@nfs.trh.sim.no> Jeremy Walton writes: > [...] have run into trouble because prefmenu is a private member of > SoWinFullViewer, and I can't access it. This problem doesn't arise > for SoQt*, where prefmenu isn't a private member of SoQtFullViewer > (there's also a handy class called SoQtPopupMenu, which doesn't > appear to have a counterpart in SoWin*). We haven't made a "proper" 1.0.0 release of SoWin, yet, but it is forthcoming soon-ish. We'll make sure this gets fixed then, as SoWin will be "sync'ed up" with SoQt 1.0. > Should I give up on SoWin and port the whole thing to SoQt? Apart from this bug you have (which is a minor issue that can probably be resolved easily): if this is actually an option for you, it would probably be wise, as basing your application code on Qt will give you a multi-platform application "for free". Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From aclemens at xs4all.nl Fri Sep 20 18:31:46 2002 From: aclemens at xs4all.nl (Arthur Clemens) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] compile errors on Mac OS X 10.2 In-Reply-To: <20020920160634.GJ571@sim.no> Message-ID: <74543FFE-CCB6-11D6-87D6-00039366A36E@xs4all.nl> Ok, all works fine for me now! So I had the wrong library. That was just the early adapter syndrome :-) Arthur Clemens > > Hm... worksforme(tm) here. > > This might well be my fault -- I uploaded the wrong Coin library to our > ftp server in the beginning. If you were unlucky enough to download the > version built against simage in the 10 minutes that it was online, that > would explain your problem. > > Could you just try to rm -rf /Library/Frameworks/Inventor.framework, > re-download the Coin binary, and re-install it? Tell me if that works > out; if not, we have a serious problem. ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From kyrah at sim.no Fri Sep 20 18:37:28 2002 From: kyrah at sim.no (Karin Kosina) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] compile errors on Mac OS X 10.2 In-Reply-To: <74543FFE-CCB6-11D6-87D6-00039366A36E@xs4all.nl> References: <20020920160634.GJ571@sim.no> <74543FFE-CCB6-11D6-87D6-00039366A36E@xs4all.nl> Message-ID: <20020920163728.GO571@sim.no> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 +----- Arthur Clemens -- Fri, Sep 20, 2002 at 06:31:46PM +0200 ---- | Ok, all works fine for me now! So I had the wrong library. | That was just the early adapter syndrome :-) :)) Well, sorry for the inconvenience. Just do feel free to shout if anything else comes up. Have a nice weekend everybody, #!/kyrah - -- Karin Kosina (vka kyrah) http://kyrah.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (Darwin) Comment: For info see http://www.gnupg.org iD8DBQE9i07A7vvdOh/igesRAud+AKCiHdw2CyuLlU7GTo+EDm1BOY/4CgCbBXcE fMIX3ycP/PFOOebv/bSws5w= =Yw5A -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From aclemens at xs4all.nl Fri Sep 20 18:45:36 2002 From: aclemens at xs4all.nl (Arthur Clemens) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] slow anti-aliasing In-Reply-To: <20020723130643.GA5136@sim.no> Message-ID: <6365BBA6-CCB8-11D6-87D6-00039366A36E@xs4all.nl> It seems that in Coin 1.0.3 the slow anti-aliasing hasn't been addressed, or not completely solved. I get some better results than with 1.0.2, but the performance hit remains unusable high. Arthur Clemens On dinsdag, jul 23, 2002, at 15:06 Europe/Amsterdam, Peder Blekken wrote: > ..and a very slow reply from us. Sorry about that. > > I also noticed that antialiasing is very slow in SoQt. It hasn't been > like > this earlier. It might seem like the OpenGL hardware accumulation > buffer > is not enabled. I'll investigate some more. > > Peder > > ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 20 23:01:44 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoGLLineWidthElement error using JackManip In-Reply-To: "Vinh To"'s message of "Wed, 18 Sep 2002 16:29:12 -0700" References: <005101c25f6b$3226d3e0$6144e88f@LONESTARR> Message-ID: <51ptv85q9z.fsf@nfs.trh.sim.no> "Vinh To" writes: > I'm getting an SoGLLineWidthElement::updategl() error saying that > I'm out of range when I try to display the following file: > > [...] > DrawStyle { > lineWidth 1 > } Strange. It'd be very surprising if an OpenGL driver didn't support a linewidth of 1.0. > I'm just using an SoWinExaminerViewer to display it. There's a debugging backdoor in the examinerviewer which lists various features about the OpenGL driver. If you tap 'glinfo' on your keyboard when the rendering canvas has focus, what does the info-window say about glLineWidth() range and granularity? The other information in the window would also be interesting to know. > When I opened the same file using TGS, I don't get the error. I believe neither SGI nor TGS Inventor do as much robustness / error checking as we do in Coin. So in general, you will much more often get early warnings when you do something wrong with the API when using Coin. > I have tried with coin-1.0.2 and coin-1.0.3. Is this a bug and is > there a simple workaround for it? ..this sounds like a bug, though. We've never heard of any problems with a glLineWidth() of 1.0 before, so some debugging will be necessary to nail this down. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 20 23:03:47 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoGLLineWidthElement error using JackManip In-Reply-To: "Vinh To"'s message of "Wed, 18 Sep 2002 16:29:12 -0700" References: <005101c25f6b$3226d3e0$6144e88f@LONESTARR> Message-ID: <51k7lg5q6k.fsf@nfs.trh.sim.no> "Vinh To" writes: > I'm getting an SoGLLineWidthElement::updategl() error saying that > I'm out of range when I try to display the following file: [...] One additional request: what is the _exact_ error message you're seeing? Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From vinh2 at email.arc.nasa.gov Fri Sep 20 23:32:46 2002 From: vinh2 at email.arc.nasa.gov (Vinh To) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoGLLineWidthElement error using JackManip References: <005101c25f6b$3226d3e0$6144e88f@LONESTARR> <51ptv85q9z.fsf@nfs.trh.sim.no> Message-ID: <005301c260ed$42e78520$6144e88f@LONESTARR> > > [...] > > DrawStyle { > > lineWidth 1 > > } > > Strange. It'd be very surprising if an OpenGL driver didn't support a > linewidth of 1.0. > > > I'm just using an SoWinExaminerViewer to display it. > > There's a debugging backdoor in the examinerviewer which lists various > features about the OpenGL driver. If you tap 'glinfo' on your keyboard > when the rendering canvas has focus, what does the info-window say > about glLineWidth() range and granularity? Here's what it says: glLineWidth():range=[1.000000, 1.000000],granularity=1.000000 It seems like there's something wrong for the range. > The other information in the window would also be interesting to know. What other info do you need? I'm just displaying that one separator. Here's the exact error message: Coin warning in SoGLLineWidthElement::updategl():2.000000 is outside the legal range of [1.000000, 1.000000] for this OpenGL implementaion's glLineWidth() settings. It was now clamped. See the documentation of SoGLLineWidthElement for information on how to the application programmer may acquire the boundary values for the legal range. When I take out the JackManip, I don't get the error message. So I think it has something to do with JackManip trying to set a line width size of 2. > > > I have tried with coin-1.0.2 and coin-1.0.3. Is this a bug and is > > there a simple workaround for it? > > ..this sounds like a bug, though. We've never heard of any problems > with a glLineWidth() of 1.0 before, so some debugging will be > necessary to nail this down. > > Regards, > Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Tue Sep 24 12:00:07 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoGtk and gtk2? In-Reply-To: Linus Akerlund's message of "Wed, 18 Sep 2002 21:00:20 +0200" References: <20020918190020.GA14112@roky.student.uu.se> Message-ID: <51wupbu2qg.fsf@nfs.trh.sim.no> Linus Akerlund writes: > Are there any plans to port SoGtk to gtk2? That will likely happen, yes. We're not actively using SoGtk internally at the moment, and we don't have any Coin Professional Edition License holders that are using it (that we know of), so it's currently quite a way down on our prioritized "to do" lists, I'm afraid. Regards, Morten, SIM. ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From hh8 at inf.tu-dresden.de Tue Sep 24 17:39:37 2002 From: hh8 at inf.tu-dresden.de (Heiko Hoffmann) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoWin - error in SoWinGLWidget.cpp Message-ID: Hi, in the actual SoWin-package from CVS the file SoWinGLWidget.cpp contains the line: SbBool SoQtGLWidgetP::isDirectRendering(void) which should be: SbBool SoWinGLWidgetP::isDirectRendering(void) best regards, Heiko ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Tue Sep 24 17:50:20 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoWin - error in SoWinGLWidget.cpp In-Reply-To: "Heiko Hoffmann"'s message of "Tue, 24 Sep 2002 17:39:37 +0200" References: Message-ID: <518z1ridz7.fsf@nfs.trh.sim.no> "Heiko Hoffmann" writes: > [SoWin compilation fix] Thanks, applied. Best regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From neveu at pacbell.net Tue Sep 24 19:20:33 2002 From: neveu at pacbell.net (Charles Neveu) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] building multithreaded/dll/debug coin Message-ID: <200209241020.33397.neveu@pacbell.net> Has anyone had any success building a multithreaded/dll/debug Coin library? The configure script builds a static/singlethreaded lib independent of what I set --with-msvcrt to. I've had the same problem with the SoQt library as well. Thanks Charles Neveu neveu@artemis.arc.nasa.gov ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From larsa at sim.no Wed Sep 25 09:39:53 2002 From: larsa at sim.no (Lars J. Aas) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] building multithreaded/dll/debug coin In-Reply-To: <200209241020.33397.neveu@pacbell.net> References: <200209241020.33397.neveu@pacbell.net> Message-ID: <20020925073953.GA12680@sim.no> Charles Neveu wrote: : Has anyone had any success building a multithreaded/dll/debug Coin library? Yes, we do it quite frequently. : The configure script builds a static/singlethreaded lib independent of what I : set --with-msvcrt to. I've had the same problem with the SoQt library as well. It generally works fine, so I suspect there is something you do differently that what is supported or something. We need more info from you to provide any help - the file "config.log" would give us most of the info we need, so if you could send it to me, I'd take a look and see what I can find. Lars J ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Radu.Ursu at sophia.inria.fr Wed Sep 25 12:16:50 2002 From: Radu.Ursu at sophia.inria.fr (Radu Ursu) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoGuiExamples make // potential bug Message-ID: <3D918D12.4000306@sophia.inria.fr> Hi, I have configured the SoGuiExamples to be buit with MSVC6. After a while I have decided to make it work with MSVC7. After a make clean and make I still have the pdb files in the directories and the linker complains about: LINK : fatal error LNK1207: incompatible PDB format in 'd:\Coincvs\SoGuiExamples \components\backgroundimg.pdb'; delete and rebuild Radu. -- Radu Ursu, Software Engineer, CGAL, INRIA Sophia-Antipolis ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Radu.Ursu at sophia.inria.fr Wed Sep 25 16:57:20 2002 From: Radu.Ursu at sophia.inria.fr (Radu Ursu) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoQt::getApplication() gone ? References: <00f401c218ca$07a1f470$6951800a@hsj.qc.ca> Message-ID: <3D91CED0.9020904@sophia.inria.fr> Hi, I have a related problem in using QMainWindow and SoQtExaminerViewer. Tells me: QPaintDevice: Must construct a QApplication before a QPaintDevice Did I do something wrong? Here is the code: class MyWindow : public QMainWindow{ }; int main (int argc, char ** argv) { QApplication app(argc, argv); MyWindow *mainwin = new MyWindow(); SoQt::init(mainwin); SoQtExaminerViewer * viewer = new SoQtExaminerViewer(mainwin); app.setMainWidget(mainwin); mainwin->resize(400, 400); mainwin->show(); app.exec(); } Philippe Debann? wrote: >Hello all, > >I initialize my SoQt application by the following: > >// ==================== > SoQt::init(argc, argv, "My App"); > QApplication *app = SoQt::getApplication(); > CMyMainWin *mainwin = new CMyMainWin(); > app->setMainWidget(mainwin); > mainwin->show(); > app->exec(); >// ==================== > >In other words, I create my own main widget (class derived from QMainWindow) >and pass it to the QApplication created by SoQt::init(). However, it seems >that SoQt::getApplication() has been removed from recent versions API. Any >particular reason for this? > >Is the preferred (i.e. stable w/ respect to future SoQt versions) >initialization method if I want to create my own main widget as follows? > >// ==================== > QApplication app(argc, argv); > CMyMainWin *mainwin = new CMyMainWin(); > SoQt::init(mainwin); > app.setMainWidget(mainwin); > mainwin->show(); // or else SoQt::show(mainwin); > app.exec(); // or else SoQt::mainLoop(); >// ==================== > >Thanks and regards, > >Philippe Debann? >Research Associate >Groupe LIS3D/LMBCAO >Ste-Justine Hospital >Montreal, Quebec >tel.:: (514) 345-4931 ext. 2597 >email : pdebanne@justine.umontreal.ca > >------------------------------------------------------------------------------ >To unsubscribe from coin-discuss, email with the subject >"unsubscribe coin-discuss". For general help, use "help" as the subject. >See http://www.coin3d.org/ for additional information. > > -- Radu Ursu, Software Engineer, CGAL, INRIA Sophia-Antipolis ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From colin at mve.com Wed Sep 25 19:01:11 2002 From: colin at mve.com (Colin Dunlop) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoQt::getApplication() gone ? In-Reply-To: <3D91CED0.9020904@sophia.inria.fr> Message-ID: <002a01c264b5$26db0020$0ec809c0@shetland> Hi - can't see anything wrong but you might try this just to make sure SoQt and SoDB et al are all up and happy before your own code and your spinning using SoQt rather than QApplication ?: class MyWindow : public QMainWindow{}; int main (int argc, char ** argv) { QApplication app(argc, argv); QWidget* p_top_widget = SoQt::init(argc, argv); // SoQt::init calls qApp->setMainWidget(p_top_widget) implicitly. MyWindow* mainwin = new MyWindow(p_top_widget); SoQtExaminerViewer* viewer = new SoQtExaminerViewer(mainwin); mainwin->resize(400, 400); SoQt::show(mainwin); // Spin baby spin.... SoQt::mainLoop(); } You can jumble the three lines into one for complete unreadability of course so you don't have to hold p_top_widget or know of it's existence by doing: < QWidget* p_top_widget = SoQt::init(argc, argv); < // SoQt::init calls qApp->setMainWidget(p_top_widget) implicitly. < MyWindow* mainwin = new MyWindow(p_top_widget); > MyWindow* mainwin = new MyWindow(SoQt::init(argc, argv)); Well not too jumbled actually :-) This is all relatively new to me but the doxygen on coin3d.org and looking into the source of SoQt explains lots... ...I'm sure d SIM Coin people have seen the error message before and I'm beginning to ramble anyway......... Col. > -----Original Message----- > From: Radu Ursu [mailto:Radu.Ursu@sophia.inria.fr] > Sent: 25 September 2002 15:57 > To: coin-discuss@sim.no > Subject: Re: [coin-discuss] SoQt::getApplication() gone ? > > > Hi, > I have a related problem in using QMainWindow and SoQtExaminerViewer. > Tells me: > QPaintDevice: Must construct a QApplication before a QPaintDevice > Did I do something wrong? Here is the code: > > class MyWindow : public QMainWindow{ > }; > > int > main (int argc, char ** argv) > { > QApplication app(argc, argv); > MyWindow *mainwin = new MyWindow(); > SoQt::init(mainwin); > SoQtExaminerViewer * viewer = new SoQtExaminerViewer(mainwin); > app.setMainWidget(mainwin); > mainwin->resize(400, 400); > mainwin->show(); > app.exec(); > } > > Philippe Debann? wrote: > > >Hello all, > > > >I initialize my SoQt application by the following: > > > >// ==================== > > SoQt::init(argc, argv, "My App"); > > QApplication *app = SoQt::getApplication(); > > CMyMainWin *mainwin = new CMyMainWin(); > > app->setMainWidget(mainwin); > > mainwin->show(); > > app->exec(); > >// ==================== > > > >In other words, I create my own main widget (class derived > from QMainWindow) > >and pass it to the QApplication created by SoQt::init(). > However, it seems > >that SoQt::getApplication() has been removed from recent > versions API. Any > >particular reason for this? > > > >Is the preferred (i.e. stable w/ respect to future SoQt versions) > >initialization method if I want to create my own main widget > as follows? > > > >// ==================== > > QApplication app(argc, argv); > > CMyMainWin *mainwin = new CMyMainWin(); > > SoQt::init(mainwin); > > app.setMainWidget(mainwin); > > mainwin->show(); // or else SoQt::show(mainwin); > > app.exec(); // or else SoQt::mainLoop(); > >// ==================== > > > >Thanks and regards, > > > >Philippe Debann? > >Research Associate > >Groupe LIS3D/LMBCAO > >Ste-Justine Hospital > >Montreal, Quebec > >tel.:: (514) 345-4931 ext. 2597 > >email : pdebanne@justine.umontreal.ca > > > >------------------------------------------------------------- > ----------------- > >To unsubscribe from coin-discuss, email > with the subject > >"unsubscribe coin-discuss". For general help, use "help" as > the subject. > >See http://www.coin3d.org/ for additional information. > > > > > > -- > Radu Ursu, Software Engineer, CGAL, INRIA Sophia-Antipolis > > -------------------------------------------------------------- > ---------------- > To unsubscribe from coin-discuss, email > with the subject > "unsubscribe coin-discuss". For general help, use "help" as > the subject. > See http://www.coin3d.org/ for additional information. ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Wed Sep 25 22:02:37 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] SoQt::getApplication() gone ? In-Reply-To: Radu Ursu's message of "Wed, 25 Sep 2002 16:57:20 +0200" References: <00f401c218ca$07a1f470$6951800a@hsj.qc.ca> <3D91CED0.9020904@sophia.inria.fr> Message-ID: <51fzvxalcy.fsf@nfs.trh.sim.no> Radu Ursu writes: > QPaintDevice: Must construct a QApplication before a QPaintDevice > Did I do something wrong? Here is the code: [...] This should work. I just tested it on a Linux box, and it works as expected there. I think I know why it fails for your configuration, though. This is under MS Windows, right? What seems likely to happen is that your final executable has been linked against *two* different instances of the Qt library -- so SoQt is using one of them, and the application code the other. SoQt is usually _implicitly_ linking in the Qt library, which means you should *not* (redundantly) add it for the executable build/linkage when writing application code on top of SoQt. So the way to rectify your problem is by just taking out qt.lib and any other Qt-libraries from your link-line / IDE's linkage setup. We're considering ways to automatically detect this situation from within SoQt, as this is getting to be a frequently encountered problem for our MS Windows users. (Just FYI, this is not a problem particular for Coin / SoQt, it's a general issue to be aware of when doing MSWin application development. One very common cause of problems is for instance to link against multiple version of the C Run-Time (CRT)). > Philippe Debann? wrote: > > > [...] However, it seems that SoQt::getApplication() has been > > removed from recent versions API. Any particular reason for this? SoQt::getApplication() was redundant, as you're always able to get to the QApplication instance by using the global "qApp" variable from Qt. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From peciva at fit.vutbr.cz Thu Sep 26 14:32:51 2002 From: peciva at fit.vutbr.cz (Peciva Jan) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] Inventor Mentor examples Message-ID: Hello, I am planning to make small tutorial for newbies in Inventor (currently only in my language). So, I am looking for some examples and 3D models on internet. Can I use Inventor Mentor examples? (Is there any license restrictions?) And where can I download them? Thank you, John ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Thu Sep 26 14:43:31 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] Inventor Mentor examples In-Reply-To: Peciva Jan's message of "Thu, 26 Sep 2002 14:32:51 +0200 (CEST)" References: Message-ID: <51r8fgzzt8.fsf@nfs.trh.sim.no> Peciva Jan writes: > Can I use Inventor Mentor examples? (Is there any license > restrictions?) SGI has released the source code for the Inventor Mentor examples under the GNU LGPL, so you should be in the clear. > And where can I download them? We have a local copy in a repository on the same CVS server and root as the Coin source code: :pserver:cvs@cvs.coin3d.org:/export/cvsroot The repository is called "IvExamples", and contains a configure-based build setup and all Mentor and Toolmaker examples, with misc local fixes versus the original SGI code. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From peciva at fit.vutbr.cz Fri Sep 27 10:37:26 2002 From: peciva at fit.vutbr.cz (PC John) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] Inventor Mentor examples In-Reply-To: References: Message-ID: <200209270837.26259.peciva@fit.vutbr.cz> Thanks Mortene for your comments about the Mentor examples license. I am quite happy you have precompiled binaries at your ftp site (Newbies will probably do not like cygwin much). However, when I was trying SoWin binaries which are about 1 year old, I found a small bug: SoWin debug library (sowin0d.lib) is linked with non-debug Coin library (coin1.lib). So, it makes it impossible to trace into Coin sources when using precompiled SoWin (and probably much more other problems with such so old release). It is not completely neccessary, but if you find some time, can you make new SoWin precompiled binaries release? Many thanks, John On 26 Sep 2002, Morten Eriksen wrote: > Peciva Jan writes: > > Can I use Inventor Mentor examples? (Is there any license > > restrictions?) > > SGI has released the source code for the Inventor Mentor examples > under the GNU LGPL, so you should be in the clear. > [...] ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Radu.Ursu at sophia.inria.fr Fri Sep 27 09:02:26 2002 From: Radu.Ursu at sophia.inria.fr (Radu Ursu) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] linker problem Message-ID: <3D940282.6080401@sophia.inria.fr> Hi, I have a problem building SoQt that happens both in the SoQt-1.0.1 and in the CVS version. I have Qt built static for MSVC7, so I need to link against qt.lib and qtmain.lib I build coin-1 this way, resulting coin1.lib, coin1.dll: (is there any possibility to build coin static?) $ ./configure --prefix=d:/coin3d_vc7 $ make install I try to build SoQt this way: $export CPPFLAGS="-Id:/coin3d_vc7/include" $ export LDFLAGS="/UQT_DLL -lwinspool" $ ./configure --prefix=d:/coin3d_vc7 --libdir=d:/coin3d_vc7/lib --with-qt=c:/qt/3.0.4.NET --includedir=d:/coin3d_vc7/include $ make install I got linker errors related to SbList getLenght and some others that the linker didn't find. When the lib SoQt is static built at run time tells me that the same getLength is not found in some dll. Yesterday the CVS version worked fine, I suspect a problem in the coin module. I am interested if the options that I use to build coin and SoQt are good. Thanks, Radu. -- Radu Ursu, Software Engineer, CGAL, INRIA Sophia-Antipolis ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Fri Sep 27 09:23:11 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] linker problem In-Reply-To: Radu Ursu's message of "Fri, 27 Sep 2002 09:02:26 +0200" References: <3D940282.6080401@sophia.inria.fr> Message-ID: <51d6qzyjz4.fsf@nfs.trh.sim.no> Radu Ursu writes: > I build coin-1 this way, resulting coin1.lib, coin1.dll: (is there > any possibility to build coin static?) You should be able to build a static version of the Coin library by specifying these options to configure: ``--enable-static'' and ``--disable-shared''. > I try to build SoQt this way: You can simplify the invocation of the SoQt configure script. You should for instance don't have to set up the Coin include path when you are setting SoQt's installation prefix to the same place as the Coin library was installed, so this can be dropped: > $export CPPFLAGS="-Id:/coin3d_vc7/include" SoQt configure/build should automatically include or exclude the QT_DLL define, so the first flag here should be unnecessary: > $ export LDFLAGS="/UQT_DLL -lwinspool" Also, SoQt is supposed to pick up all dependencies, so you shouldn't have to explicitly specify the "-lwinspool" library either. (If configure or build fails without it, it'll be considered a bug in our SoQt configure script.) > $ ./configure --prefix=d:/coin3d_vc7 --libdir=d:/coin3d_vc7/lib > --with-qt=c:/qt/3.0.4.NET --includedir=d:/coin3d_vc7/include You can drop ``--libdir'' and ``--includedir'' here. If the QTDIR environment variable is set, you can also drop the ``--with-qt'' option. > I got linker errors related to SbList getLenght and some others that > the linker didn't find. Is that for the final SoQt-library link? Or does SoQt link ok, but not executable built on top of SoQt / Coin? Could you please cut'n'paste the exact output from the linker, and mail it to us? > Yesterday the CVS version worked fine, I suspect a problem in the > coin module. Strange -- we haven't made any changes lately that should be able to cause this to suddenly fail. > I am interested if the options that I use to build coin and SoQt are > good. Apart from some redundancy, as I commented above, they seem fine. They should certainly not cause linkage to fail. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From neveu at pacbell.net Fri Sep 27 10:18:33 2002 From: neveu at pacbell.net (Charles Neveu) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] threads colliding in SoDB::startNotify, endNotify Message-ID: <200209270118.34295.neveu@pacbell.net> I've got a multithreaded application (Coin 1.0.3 and SoQt 1.0.1, Windows 2000) that is crashing when two threads try to access SoDB:startNotify/endNotify simultaneously. I put mutexes around all my code, but there are still SoDB:startNotify/endNotify calls that occur because Qt is generating events that cause the scene to render, that don't pass through my code at all, and they occasionally collide with one of my threads in this section of SoDB. I'm using a subclass of SoQtExaminerViewer. Can I use SoDB::isNotifying()? Can I turn off notification globally? Do I need to do anything special for multithreaded apps, like a different init functions? Thanks, Charles ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Radu.Ursu at sophia.inria.fr Fri Sep 27 11:57:43 2002 From: Radu.Ursu at sophia.inria.fr (Radu Ursu) Date: Sat Jul 30 15:53:41 2005 Subject: [coin-discuss] linker problem Message-ID: <3D942B97.6060009@sophia.inria.fr> My previous config.log was a good one. This time contains the results searching the Qt devkit. Morten Eriksen wrote: > SoQt configure/build should automatically include or exclude the > QT_DLL define, so the first flag here should be unnecessary: > >> $ export LDFLAGS="/UQT_DLL -lwinspool" >> > > Also, SoQt is supposed to pick up all dependencies, so you shouldn't > have to explicitly specify the "-lwinspool" library either. (If > configure or build fails without it, it'll be considered a bug in our > SoQt configure script.) > If I don't define LDFLAGS I get: checking for Qt library devkit... UNRESOLVED I have attached the config.log. It's working with LDFLAGS="-lwinspool". >> I got linker errors related to SbList getLenght and some others that >> the linker didn't find. >> > > Is that for the final SoQt-library link? Or does SoQt link ok, but not > executable built on top of SoQt / Coin? > > Could you please cut'n'paste the exact output from the linker, and > mail it to us? > I have attached the error.txt that contains the linker messages. And the soqt-default.cfg that I guess is used to build the library. Coin - CVS version (lib not static version) SoQt - CVS version (lib not static version) Once again it's very strange because yesterday behaved different. By the way, with VC6 and Qt as static lib, the piece of code trying to create a viewer as a child of a custom widget give me the same answer that I should create a QApplication before creating a QPaintDevice. Radu. -- Radu Ursu, Software Engineer, CGAL, INRIA Sophia-Antipolis -------------- next part -------------- A non-text attachment was scrubbed... Name: report.zip Type: application/x-zip-compressed Size: 17153 bytes Desc: not available Url : /pipermail/coin-discuss/attachments/20020927/261f949e/report.bin From pederb at sim.no Fri Sep 27 11:58:42 2002 From: pederb at sim.no (Peder Blekken) Date: Sat Jul 30 15:53:42 2005 Subject: [coin-discuss] threads colliding in SoDB::startNotify, endNotify In-Reply-To: <200209270118.34295.neveu@pacbell.net> References: <200209270118.34295.neveu@pacbell.net> Message-ID: <20020927095842.GA5322@sim.no> On Fri, Sep 27, 2002 at 01:18:33AM -0700, Charles Neveu wrote: : I've got a multithreaded application (Coin 1.0.3 and SoQt 1.0.1, Windows 2000) : that is crashing when two threads try to access SoDB:startNotify/endNotify : simultaneously. I put mutexes around all my code, but there are still : SoDB:startNotify/endNotify calls that occur because Qt is generating events : that cause the scene to render, that don't pass through my code at all, and : they occasionally collide with one of my threads in this section of SoDB. I'm : using a subclass of SoQtExaminerViewer. Can I use SoDB::isNotifying()? Can I : turn off notification globally? Do I need to do anything special for : multithreaded apps, like a different init functions? Coin-1 isn't thread safe at all so you'll need to protect all your code that access the scene graph to make sure two threads don't access the scene graph simultaneously. The easiest thing to do is probably to have a global mutex that a thread must lock before accessing the scene graph. Also, in your viewer class, you should override SoQtExaminerViewer::actualRedraw() to make it look something like this: void MyViewer::actualRedraw(void) { myglobalcoinmutex.lock(); SoQtExaminerViewer::actualRedraw(); myglobalcoinmutex.unlock(); } This will make sure the rendering thread have locked the mutex before rendering the scene graph. If you need a thread safe version of Coin, Coin-2 has some support for this. We've made Coin-2 thread safe for some selected functionality. This includes action traversal (rendering) and scene graph notification. Best regards, Peder ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From carlos at reyes.stanford.edu Fri Sep 27 18:37:36 2002 From: carlos at reyes.stanford.edu (Carlos E. Cardenas S.) Date: Sat Jul 30 15:53:42 2005 Subject: [coin-discuss] Precompiled releases 1.0.3 for window Message-ID: <3D948950.DBCF2D0E@reyes.stanford.edu> Hi! Is there a precompiled release (version 1.0.3) for windows available? Thanks, Carlos ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Sat Sep 28 15:09:55 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:42 2005 Subject: [coin-discuss] Precompiled releases 1.0.3 for window In-Reply-To: "Carlos E. Cardenas S."'s message of "Fri, 27 Sep 2002 09:37:36 -0700" References: <3D948950.DBCF2D0E@reyes.stanford.edu> Message-ID: <51wup6tg4c.fsf@nfs.trh.sim.no> "Carlos E. Cardenas S." writes: > Is there a precompiled release (version 1.0.3) for windows > available? Sorry, not yet. Our build- & packaging-dedicated Windows-box went up in flames last week (well, not literally), and we've just been able to replace the faulty motherboard. A binary installation package for 1.0.3 should be forthcoming early next week. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From neveu at artemis.arc.nasa.gov Sun Sep 29 02:58:50 2002 From: neveu at artemis.arc.nasa.gov (Charles Neveu) Date: Sat Jul 30 15:53:42 2005 Subject: [coin-discuss] dragger bug? Message-ID: I'm trying to use a dragger but coin 1.0.3 generates a warning (SbMatrix::inverse(): Determinant of matrix is zero). It looks like the matrix in question is THIS->draggercache->draggerToWorld which is passed as an argument to SbProjector::setWorkingSpace; it has the value -4.31602e+008 for every element. SbMatrix SoDragger::getLocalToWorldMatrix(void) { assert(THIS->draggercache); SbMatrix m = THIS->draggercache->draggerToWorld; m.multLeft(this->getMotionMatrix()); return m; } The stack trace looks like this SoError::handleError() line 297 + 11 bytes SoDebugError::postWarning(const char * const 0x102524b8, const char * const 0x10252498) line 264 + 177 bytes SbMatrix::inverse() line 305 + 15 bytes SbProjector::setWorkingSpace(const SbMatrix & {...}) line 129 + 12 bytes SoTranslate2Dragger::drag() line 290 + 48 bytes SoTranslate2Dragger::motionCB(void * 0x00000000, SoDragger * 0x015758e0) line 237 SoCallbackList::invokeCallbacks(void * 0x015758e0) line 124 + 22 bytes SoDragger::handleEvent(SoHandleEventAction * 0x014f77b0) line 1444 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x015758e0) line 869 SoAction::traverse(SoNode * const 0x015758e0) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 1) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoGroup::doAction(SoAction * 0x014f77b0) line 280 SoSeparator::doAction(SoAction * 0x014f77b0) line 243 SoSeparator::handleEvent(SoHandleEventAction * 0x014f77b0) line 541 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x01553b00) line 869 SoAction::traverse(SoNode * const 0x01553b00) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 12) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoGroup::doAction(SoAction * 0x014f77b0) line 280 SoSeparator::doAction(SoAction * 0x014f77b0) line 243 SoSeparator::handleEvent(SoHandleEventAction * 0x014f77b0) line 541 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x01542a00) line 869 SoAction::traverse(SoNode * const 0x01542a00) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 0) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoBaseKit::doAction(SoAction * 0x014f77b0) line 961 SoBaseKit::handleEvent(SoHandleEventAction * 0x014f77b0) line 1016 SoDragger::handleEvent(SoHandleEventAction * 0x014f77b0) line 1456 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x01540490) line 869 SoAction::traverse(SoNode * const 0x01540490) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 0) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoTransformManip::doAction(SoAction * 0x014f77b0) line 282 SoTransformManip::handleEvent(SoHandleEventAction * 0x014f77b0) line 366 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x01532530) line 869 SoAction::traverse(SoNode * const 0x01532530) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 2) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoGroup::doAction(SoAction * 0x014f77b0) line 280 SoSeparator::doAction(SoAction * 0x014f77b0) line 243 SoSeparator::handleEvent(SoHandleEventAction * 0x014f77b0) line 541 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x0157d370) line 869 SoAction::traverse(SoNode * const 0x0157d370) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 13) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoGroup::doAction(SoAction * 0x014f77b0) line 280 SoSeparator::doAction(SoAction * 0x014f77b0) line 243 SoSeparator::handleEvent(SoHandleEventAction * 0x014f77b0) line 541 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x0150d670) line 869 SoAction::traverse(SoNode * const 0x0150d670) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 0) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoGroup::doAction(SoAction * 0x014f77b0) line 280 SoSeparator::doAction(SoAction * 0x014f77b0) line 243 SoSeparator::handleEvent(SoHandleEventAction * 0x014f77b0) line 541 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x014fd450) line 869 SoAction::traverse(SoNode * const 0x014fd450) line 745 + 48 bytes SoChildList::traverse(SoAction * const 0x014f77b0, const int 0, const int 4) line 271 SoChildList::traverse(SoAction * const 0x014f77b0) line 303 SoGroup::doAction(SoAction * 0x014f77b0) line 280 SoSeparator::doAction(SoAction * 0x014f77b0) line 243 SoSeparator::handleEvent(SoHandleEventAction * 0x014f77b0) line 541 SoNode::handleEventS(SoAction * 0x014f77b0, SoNode * 0x014fada0) line 869 SoAction::traverse(SoNode * const 0x014fada0) line 745 + 48 bytes SoHandleEventAction::beginTraversal(SoNode * 0x014fada0) line 317 SoAction::apply(SoNode * 0x014fada0) line 469 SoSceneManager::processEvent(const SoEvent * const 0x014f8ef0) line 210 SoQtRenderArea::processSoEvent(const SoEvent * const 0x014f8ef0) line 1845 + 27 bytes SoQtViewer::processSoEvent(const SoEvent * const 0x014f8ef0) line 3234 + 24 bytes SoQtFullViewer::processSoEvent(const SoEvent * const 0x014f8ef0) line 702 + 24 bytes SoQtExaminerViewer::processSoEvent(const SoEvent * const 0x014f8ef0) line 368 + 30 bytes SoQtRenderArea::processEvent(QEvent * 0x0012fb60) line 1901 + 15 bytes SoQtGLWidgetP::eventFilter(QObject * 0x014fe1a0, QEvent * 0x0012fb60) line 848 QT-MT304! 39d539f7() QT-MT304! 39d5395d() SoQtGLArea::event(QEvent * 0x0012fb60) line 159 QT-MT304! 39d27b53() QT-MT304! 39d277cd() QT-MT304! 39d05a8b() QT-MT304! 39d0973a() USER32! 77e727fe() USER32! 77e72889() OPENGL32! 755ba950() USER32! 77e71820() 013c0197() Charles -- Dr. Charles Frederick Neveu T: 650 604-2525 Autonomy and Robotics Group F: 650 604-4036 QSS Group, Inc. E: neveu@ptolemy.arc.nasa.gov Mail Stop 269-4 W: http://ic.arc.nasa.gov/people/neveu NASA Ames Research Center Moffett Field, CA 94035-1000 ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From Matthias.Stiller at epost.de Mon Sep 30 01:25:02 2002 From: Matthias.Stiller at epost.de (Matthias Stiller) Date: Sat Jul 30 15:53:42 2005 Subject: [coin-discuss] strange behaviour In-Reply-To: <51wup6tg4c.fsf@nfs.trh.sim.no> References: <3D948950.DBCF2D0E@reyes.stanford.edu> <51wup6tg4c.fsf@nfs.trh.sim.no> Message-ID: <200209300125.02626.Matthias.Stiller@epost.de> Hi, I am currently facing an interesting behaviour. I have a small app which consists mainly of an examinerviewer which allows various objects to be selected (with Box or LineHighlightSelection). When moving the complete application window around (and afterward releasing it) sometimes the selected objects will only get painted in normal mode but not the additional selection. System: GeForce 2 MX with recent driver for SuSe 8.0, Coin 1.0.3, Qt 3.1b1 and SoQt 1.0.1 Any ideas what the source of the problem could be ? Regards Matthias ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information. From mortene at sim.no Mon Sep 30 10:46:58 2002 From: mortene at sim.no (Morten Eriksen) Date: Sat Jul 30 15:53:42 2005 Subject: [coin-discuss] strange behaviour In-Reply-To: Matthias Stiller's message of "Mon, 30 Sep 2002 01:25:02 +0200" References: <3D948950.DBCF2D0E@reyes.stanford.edu> <51wup6tg4c.fsf@nfs.trh.sim.no> <200209300125.02626.Matthias.Stiller@epost.de> Message-ID: <51wup33lvh.fsf@nfs.trh.sim.no> Matthias Stiller writes: > I am currently facing an interesting behaviour. :-} > I have a small app which consists mainly of an examinerviewer which > allows various objects to be selected (with Box or > LineHighlightSelection). When moving the complete application window > around (and afterward releasing it) sometimes the selected objects > will only get painted in normal mode but not the additional > selection. Does this also happen if you run our SoGuiExamples/nodes/selection example? If not, I guess we would have to see your code. If yes, debugging gets complicated. :-/ > Any ideas what the source of the problem could be ? Not yet. Regards, Morten ------------------------------------------------------------------------------ To unsubscribe from coin-discuss, email with the subject "unsubscribe coin-discuss". For general help, use "help" as the subject. See http://www.coin3d.org/ for additional information.