Closed lambdam94 closed 4 years ago
Yes - Good contribution.
Will add
Problem is we really should check all shapes, just in case of errors from typo's
If you could eye ball the changes in branch enum_lunit before I merge with master. There are a lot of changes so want to avoid errors due to typo's. I will then merge and test.
There is only 2 IndentationError on lines 2155 and 2156. Otherwise, the 7 GDML objects work well.
line43 #print('setMaterial') and line45 obj.lunit = LengthQuantityList can be deleted (no longer used).
Thanks! Regards Dam
Should now be good - have merged into master
Great! Thanks! Dam
Le mer. 15 juil. 2020 à 20:05, Keith Sloan notifications@github.com a écrit :
Should now be good - have merged into master
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/KeithSloan/GDML/issues/28#issuecomment-658917768, or unsubscribe https://github.com/notifications/unsubscribe-auth/APAHWHE6EVK6O5F5YIZTMHDR3XVU7ANCNFSM4O2JXTTA .
Perfect! Thanks!
Hello Keith,
Freecad can deal with 7 different length types ['nm','um', 'mm','cm', 'dm','m', 'km'] (cf. https://wiki.freecadweb.org/Quantity). So we can propose a enumeration for lunit in each part definition.
I tried to do this for GDMLBox in GDMLObject.py.
I add at the beginning of the file:
And line 355 I replace
obj.addProperty("App::PropertyString","lunit","GDMLBox","lunit").lunit=lunit
by:We should do quite the same for each class - object definition: GDMLArb8: line ~275 GDMLCone: line ~425 GDMLElCone: line ~516 cf. GDMLObjects.py.txt etc.
Do you think it is a good idea to add this? Thanks!
Regards Dam