Fri, 09/29/2006 - 19:13
Forums:
Will be any soon update for OpenCascade from Qt3 to Qt4?
Reasons:
- I can't find any Qt3 release for windows on the Qt - Trolletch
- I can't port direct from Qt3 and Qt4 are not binary compatible
Collaborative development portal
Fri, 09/29/2006 - 21:07
You can find an open source QT 3.3.6 Win32 on the QTWin project in Sourceforge. I haven't tried using this yet as I'm concentrating on building a new native Win32 OCC6.1 harness under QT4 - there are a number of references in the internet who say this works well, but I can't find any code yet. I've already got OCC and QT4/Coin3d running under VS2005 with clean builds and I'm now looking to start joining them up, learning QT4 along the way. For those intertested I have a single build project that compiles OCC from the ground up - I've got a simple fix for the variable loop scoping "gotcha" if anyone is intertested.
Pete
Thu, 10/05/2006 - 17:11
OpenCascad6.2 works well with QT4.2! I've tryed the tutorial and it works!
markus
Fri, 10/06/2006 - 15:29
I have OpenCascade6.0 and works with QT3.3.3! (I'l try OpenCascade6.2)
(setup-qt-win-free-msvc.net2003-3.3.3-2.exe)
Mon, 10/16/2006 - 22:44
OpenCASCADE 6.2 ???? I assume you mean 6.1. For those using QTWin, there's a recent update to patch the open source Windows Qt 4.2 release - its worth playing with.
I've been looking at the various Qt and MFC examples and have eventually come to the conclusion that there are some really obtuse design decisions in the object model used. Its not clear what the distinction between a view, document, MDIWindow and so on is trying to achieve. What object is responsible for syncronising views of the same OCC context, what object should handle file import/export - it seems to be all over the place. This is making re-use of the code difficult and this seems at odds with the relatively clean object modelling with OCC itself.
So I've had a go at trying to resolve this issue - and the obvious place to start is with the OCC view itself as it gives the most immediate visual response (aka fun!) and should be applicable to both MDI and SDI applications (and who uses MDI in real OCC applications anyway). I now have a new Qt4 widget called (not originally) QOCCWidget. This is based on purely Qt4 objects, and is a sub-class of QGLWidget. I've fixed most of the flicker problems using solutions presented elsewhere on the forum, and am now starting on the rubberbanding problem (also noted elsewhere on the forum). In my model the view is only responsible for moving the object around the screen - any specific user input such as mouse clicks should be designed as a "signal" for another consumer QObject to handle in a "slot". This new widget can be easily plugged into any Widget container - I've currently got a GUI harness (based on MonkeyStudio's UiMain.ui) that should evolve into a general purpose harness - for Coin3d and VTK as well. Currently the harness is responsible for creating the AIS context which is then used to initialise the view widget, but this is likely to move out to its own object (QOCCDocument?). I've found this makes the object model separation much clearer and better aligned to the Qt4 architecture. I've also decided that I really don't like the panning, zooming model using the CTRL key - its clumsy - so I'm going to change it, probably to use specific interaction modes set up though the GUI container.
The upshot to this is that I think there is a much better Qt4/OCC object model than the one provided. Is there any intertest in developing this collaboratively for the benefit of all? I have no problem sharing my code but it is specifically targetted for OCC 6.1/Qt 4.2/VS 2005. I know there are much better coders than out there than I. What do you think?
Pete
Tue, 10/17/2006 - 11:59
> OpenCASCADE 6.2 ???? I assume you mean 6.1. For those using QTWin, there's a recent update to
> patch the open source Windows Qt 4.2 release - its worth playing with.
Where can I find the patch?
Tue, 10/17/2006 - 14:11
redmonk
Looking on the Sourceforge site, there's now a p3 patch that I need to download.
Here's the link
http://sourceforge.net/project/showfiles.php?group_id=49109&package_id=1...
Pete
Wed, 10/18/2006 - 11:47
OpenCascade 6.1 [latest public version] is incompatible with Q4+ [played with Q4.2]
The "Automatic" porting to from qt3to4 porting tool doesn't work too.
[at least as suspected]
Wed, 10/18/2006 - 12:13
I'm not sure what you mean about incompatible - that's not my findings. Using qt3to4 to port the OCC Qt3 samples was painful - having to change a whole bunch of QList's into Q3PtrList's just to recover a "next()" method. I did get it working of a sort but had the old problems with resize and flicker. Thats why I went for a clean port using a Qt4 object model that (I hope) is not dependent on the Qt3 support objects. If you like, I should be able to take the view I've got and shove it into a very simple application harness and host the resulting Doxygen output with source on my own site for you to view. Interested?
Pete
Thu, 10/26/2006 - 15:21
It would be interesting to see how you set up the model/view within the Qt4 paradigm.
I'm looking for a modeling kernel with my architectural design application and OpenCASCADE seems a usable candidate (and cheaper then ACIS or parasolid).
Thu, 10/26/2006 - 21:58
Stefan
For the moment I've concentrated on trying to achieve a simple mechanism for rendering OCC 6.1 in a Qt4 widget. So far I've created two objects, QOCCWidget that handles a single view instance and QOCCViewerContext that wraps the AIS_InteractiveContext and V3d_Viewer together. This latter object currently provides my "document" context, although I see it eventually as delegation class within a higher QOCCDocument object (perhaps based on OCAF). Its still a work in progress - currently I'm looking at adding grids - and once I have some of the groundwork done I'll look to designing it as a framework. I've uploaded a Doxygen output (with links to source) from work I've done so far on my web - but it will be subject to change.
http://myweb.tiscali.co.uk/dolbey/Doxygen/QOCC/
As you will see these are mostly based on the standard apps, and offer no user interface yet. I have one, but I'm intending to knock up a minimal GUI just to illustrate the principles I'm working on. Once this is done, I'll build a small .pro based project zip file and shove that up on the web as well. "Theoretically" it should be platform dependent, but I'm a Windows developer at heart so I'll leave the proof of this to others.
I'm considering whether its worth trying to start-up a project for this activity, either here or on SourceForge (for me its just entertainment these days) - Anybody else interested in this?
Pete
Fri, 10/27/2006 - 12:21
I am interested can do you send it to me? (VS 2005, QT 4.2, OCC 6.0/6.1)
Fri, 10/27/2006 - 14:13
Anyone looking at this early cut of code will find that it still actually doesn't actually compile without Qt3 support - the Qt3 objects are removed, but not all of the Qt3 "enums". I've complained to the developer who assures me that this will be fixed in the next release.
Pete
Sun, 10/29/2006 - 07:25
OK, I've put up a Qt4 4.2.1 / OpenCASCACDE 6.1 simple "Bottle Viewer" up on web-site - ignore the previous link, I've not got a complete example documented at http://myweb.tiscali.co.uk/dolbey/QtOpenCascade/doc/html/
If anyone wants to have a play with this, the source with its qmake project files can be found in http://myweb.tiscali.co.uk/dolbey/QtOpenCascade.zip.
Assumming you have all yout paths and environment variables in place (remember that is built for vs2005) - its should just be a matter of running
qmake
nmake
in the src directory.
Pete
Sun, 10/29/2006 - 16:07
My Qt4 example can now be accessed from
http://myweb.tiscali.co.uk/dolbey/QtOpenCascade/
Pete
Mon, 10/30/2006 - 18:09
QT 4.2 Com / OCC 6.1 / VS 2005 - after some modification compile/link Ok.
But I get a error at run (debug and release) malloc.c [malloc_base (size_t size)]!
Mon, 10/30/2006 - 20:53
What was the modification?
Where was the error?
In what version of compiler is your OCC6.1 built?
Pete
Thu, 11/02/2006 - 17:22
Why have you try to recompile OCC6.1 [DEFINES += QTOPENCASCADE_NO_DLL] ?
I am tyring to build the project with the default compile of OCC6.1.
Thu, 11/02/2006 - 20:20
Ah you found that did you!
My plan is that the QtOpenCascade class components are used as an API within a DLL. This is how I originally built them. This requires each class to be specified with a _declspec(dllexport | dllexport). Qt4 wraps this with (from memory as I'm still at work) Q_DECL_IMPORT/Q_DECL_EXPORT macros which switches for the dll or client builds - its similar to the Standard_EXPORT macro used by OCC. It is still my intention to use this model for my "target" architecture, but for the demo application I was getting linkage errors so I used this DEFINE to unpick the library macros.
Its a useful trick for building and testing simple harnesses before turning them into an API.
How's the malloc error going. I never fully pointed out that I have completely recompiled OCC6.1 onto VS2005, hence all my code (application,Qt4, OCC, VTK and so on) is using the same Microsoft run-time. If you need to do this to fix a potential binary incompatibility (your original diagnosis), then let me know and I'll mount up another small document describing the methods and a zip containing my VC2005 sln's and vcproj's - I use a single sln to compile the complete suite mostly in the right order.
Pete
p.s. The relevant code macros from QtOpenCascade.h are in the doxygen output (and here they are again).
#ifdef QTOPENCASCADE_LIB
00022 # define QTOPENCASCADE_EXPORT Q_DECL_EXPORT
00023 #else
00024 # define QTOPENCASCADE_EXPORT Q_DECL_IMPORT
00025 #endif
00026
00027 // This is used to test local linkage
00028 #ifdef QTOPENCASCADE_NO_DLL
00029 #undef QTOPENCASCADE_EXPORT
00030 #define QTOPENCASCADE_EXPORT
00031 #endif
Thu, 11/02/2006 - 20:29
Should read "_declspec(dllimport | dllexport)".
Mon, 12/04/2006 - 15:09
Tks! now works.
Mon, 12/04/2006 - 21:21
Problems with the version found so far.
1. In my pri file, I included the WOK and DRAWEXE libs which won't be there unless you recompile OCC from scratch.
2. When the viewer uses some of the built-in Qt cursors for panning/zooming, it doesn't always redraw them correctly. Native windows cursors seem OK.
I've got some "fun" grid managers in my current version, and I'm still trying to perfect my point-on-plane algorithm.
Pete
Sat, 12/16/2006 - 07:51
Theres a few small issues with compiling this on linux that I corrected. If you want I'll make a patch.
Sat, 12/16/2006 - 08:31
Marc
Please send me what you've done. You may see on another thread a problem I've been having with the Qt4 that's stalled me a bit. However I have not made any c++ changes that are non-portable, so I'd be VERY interested to see what you've done. And once I've added a simple brep loader I'll up date the site with the merged changes, although I might still need you test them (if you don't mind).
You can it send to (with the usual replacements) "peter at dolbey dot freeserve dot co dot uk (but I may respond on a different address).
Pete
Tue, 12/19/2006 - 06:50
Sent. Nothing dramatic from what I remember (it was done on 11-15)
I'm also updating exoTK to run with QT3 and OCC 6.1. Currently running actually, just need a few tests and I'll post that up someplace as well. exoTKAD is actually not a bad framework for a future app.
Tue, 12/19/2006 - 07:45
Hi Marc,
I ported my code to OCC6.1 with the MFC user-interface but i didn't posted it because it's not yet completly finished.
I'm planning to continue developing exoTKAD next year as I may have more time to do it.
BTW, i was thinking of switching to another GUI framework like wxWidgets.
Or developping a C# GUI (compatible with Mono if possible).
AS the GUI is totally independant of the core libraries, it is not a big deal to replace it.
I've done the port from MFC to Qt in 3 days if i remember correctly.
I will see....
Keep in mind the the exoTKAD source code is licensed under GPL, so you cannot use the code in commercial applications.
Stephane
http://www.exotk.org
Tue, 12/19/2006 - 15:41
Thanks Mark, I've got the files. I'll diff them against the originals that I uploaded to see what changes you made. However I've been trimming the view class down - most open source application seem to be based on the original turorial Qt/MFC codes, yet when you takle them apart you find them quite inefficient. For instance the old degenerate mode switches etc. - these functions are deprecated in 6.1
I'll try to incorporate your amendments and update the site, but it would be useful if you check them out for me. I'm trying to keep the major elements portable.
Your right about exoTK - I have been checking it over, especially in the area of i/o. But it looked like it had come to a standstill in 2002. Good to see the Stephane is still working on it.
Most of the problems I had trying to upgrade it related to Stephane's use of #defines to re-write new code from OCC classes, which isn't a very good technique for maintainability. However, there's so much other good stuff in his library that I'm trying to work out how to fit it in. Its a pity that Stephane is considering a move away from Qt, especially as it now support more open soure platforms (with the help of qtwin).
Pete
Tue, 12/19/2006 - 16:32
"Your right about exoTK - I have been checking it over, especially in the area of i/o. But it looked like it had come to a standstill in 2002."
It did, I'm trying to revive it. I'm going to attempt to contact him perhpas it can live again. Minor changes have it running now. If nothing else the import filters can be of use to you. But the app seems ready to expand, and the code seems clean.
Sat, 12/16/2006 - 08:35
Oh and ignore the " (I was going to quote the address). Oh for a post editor here!
Pete