2012/10/16, jelle feringa <jelleferi...@gmail.com>: >> I think as Python coders we all agree that "simple is better than >> complex". However, I have to use TDocStd because I need its undo/redo >> functionality. >> > > Good point. > > >> I'll have a look at the examples you suggested. They don't work out of >> the box for me because I'm using the Debian packages of Traits, and >> those have a different api. If you want me to I can send patches when >> I get them to work with the Debian traits package. >> > > Which version of traits are you running? > But perhaps just glancing over the code might provide you some insight.
Unfortunately I found out that the Debian-specific changes in Traits were not the only problems here. As far as I can tell the only changes required to get Traits working in Debian are these: import enthought.traits -> import traits import enthought.traits.ui -> import traitsui However I ran into more problems with pythonOCC: in "ocaf_browser.py" line 72: TDataStd.TDataStd_Shape does not exist in "InteractiveFeatureTree/framework.py" line 45: "ts.NewChild(root)" fails: "wrong number of attributes for overloaded function" Looking at [1] my guess is that NewChild() does not expect to receive "self" as its first argument. [1] http://api.pythonocc.org/OCC.TDF.TDF_TagSource-class.html However, I have looked through the source code as you suggested. Unfortunately I haven't found any hints for solving my problem. > >> Let me clarify that my problem is not caused by an issue or a bug of >> pythonOCC. It's rather caused by the lack of documentation for OCC. > > > Are you familiar with the doxygens / pdf docs from OCC? > There's no way of working with advanced OCC programming without this. > Its not perfect, but pretty decent. I'm aware of the pdf docs and I'm using the class references from api.pythonocc.org and sourcearchive.com. Unfortunately I didn't find any information there that covers this specific topic. I was just hoping that somebody from this list would already have some experience with this. By the way, it took me a long time to find the pdf docs and api documentation when I started using pythonOCC and I think it would be a good idea to advertise them more. >> I just arrived at this solution as a result of many experiments and my >> current solution right now is a very ugly workaround that I really >> want to get rid of. >> >> Nonetheless, here's a short explanation of what I'm currently doing: >> My solution involves keeping a list of all the shapes which are part >> of the document. When a shape is selected and "Del" is pressed, the >> program iterates over all shapes and deletes the first one for which >> some_shape.IsEqual(selected_shape) returns True. In my example you can >> see that when you try to delete one of the boxes: The right box is >> just a copy of the left box. If any of the boxes is selected and "Del" >> is pressed, the left one will be deleted because it appears first in >> the list. >> > > Interesting. Not sure if this is a bug or feature. If the left box is a > child of the right one, isnt it expected that the geometry downstream is > deleted too? > Or is that a poor apology ;) > > Attached: some docs related to OCAF. > Please note that this is NOT the API documentation [ you will need that too > ] > > -jelle > _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
