-about- pythonOCC aims to provide a full Python wrapper for the OpenCascade's 3D CAD modeling/visualization library classes. The first step is to focus on modeling and import/export classes (IGES, STEP, VRML) in order to provide a complete, powerful, and easy- to-use 3D modeler using Python scripts. -changes- The pythonOCC build is now modular. New OpenCascade smart pointers management. Many additional modules. Improvements in the visualization part. Interactive console fixes and enhancements. Availability for Windows, Linux, and Mac OS X. www.pythonocc.org / https://gna.org/projects/pythonocc/ Dear all, It's my pleasure to inform you that pythonOCC 0.1 has been released. This is a huge step in the development of pythonOCC, where we went from a monolithic build, to a modular approach. That makes it far easier to distribute pythonOCC based apps and speeds up the development process by a great deal. Nearly the whole OCC API is currently wrapped in pythonOCC. The 0.1 release sets the foundation of what's to come the following years. pythonOCC is no longer a proof-of- concept it represents the start of Agile CAD development. My appreciation goes out to Thomas Paviot, who has made a massive effort in getting pythonOCC to where it is today. What's next? * Like Thomas mentions on the front page of the pythonOCC site, the work has only just begun. The aim of pythonOCC is not to merely wrap OCC, but to provide a high-level, pythonic API. An example is the Topology.py in the utils directory. An idea is to make a high level declarative api. Such that vertex.x = 12.0 would deal with all the intrinsics involved in updating the coordinate of a given vertex. The api would follow OCC's topology: Vertex, Edge, Face, Solid. The traits module developed by Enthought makes event based programming a pleasure, and provides hooks for a gui based on introspection. http://code.enthought.com/projects/traits/ This is just one example of what the high level api could look like. We'd appreciate having your ideas / input on this topic very much, you're invited to share these at the project site. * Given the solid state of the .1 release, its time to formalize the development process. Let's start using the bugtracker, task manager and the other neat features the project site offers. See https://gna.org/projects/pythonocc/ * OCC SVN. Currently OCC is distributed as a .tar archive, rather than on version control. We need to fix that. We're thinking of putting OCC under version control, such that bug fixes, patches, etc. can all be merged on one single repository. The OCC community as a whole would profit from that, and hopefully become more cohesive. * Move the GUI from Wx to QT. Wx is problematic to support on OSX, also we expect QT momentum to spike given that the upcoming 4.5 release will be lgpl'd. * PR. pythonOCC needs reach out and get in the open. We're thinking of giving a presentation at EuroPython. Did you know that an early ancestor of OCC was used to construct the Concorde? That OCC is a close relative of Unisurf, the software by Bézier that sparked the development of CAD? We need the Bézier's of our time developing on top of pythonOCC. * Agile CAD. Planning on writing a paper on Agile CAD development / Open Source CAD development. pythonOCC is the underpins being able to develop CAD apps in a short timeframe, with an OS license. pythonOCC should become the premier OS CAD platform. Thanks so much for all the received feedback and we're looking forward to your continued involvement in pythonOCC. The future of Agile CAD development is looking bright! - Thomas Paviot - Jelle Feringa -