[Discussion] Splitting Draft tools into their own modules

A forum dedicated to the Draft, Arch and BIM workbenches development.
User avatar
Joel_graff
Posts: 1537
Joined: Fri Apr 28, 2017 4:23 pm
Contact:

Re: [Discussion] Splitting Draft tools into their own modules

Postby Joel_graff » Thu Nov 07, 2019 1:22 pm

looo wrote:
Thu Nov 07, 2019 10:02 am
It would be fantastic to have a clear proposal for all this uploaded to github. Then we can collaborate on the structure of FreeCAD 1.0 and work out solutions on how to get there.
I would definitely like to see the Workbench-Starterkit architecture aligned as closely as possible with FEM / Draft (refactored). I don't think it's wrong for it to lack a lot of the implementation details found in other workbenches, but if a new dev wants to "do xxx like it's done in FEM / Draft", the structure of Workbench-Starterkit should readily accommodate that, without inheriting a lot of unnecessary code baggage.
FreeCAD Trails workbench for transportation engineering: https://www.github.com/joelgraff/freecad.trails

pivy_trackers 2D coin3D library: https://www.github.com/joelgraff/pivy_trackers
vocx
Posts: 1590
Joined: Thu Oct 18, 2018 9:18 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby vocx » Fri Nov 08, 2019 4:32 pm

looo wrote:
Thu Nov 07, 2019 10:02 am
It would be fantastic to have a clear proposal for all this uploaded to github. Then we can collaborate on the structure of FreeCAD 1.0 and work out solutions on how to get there.

edit: please also have a look here: https://forum.freecadweb.org/viewtopic. ... 50#p345850
Yes, although it's still a bit premature, I think. I personally don't want to see FreeCAD rushed to 1.0 any time soon. I think we should make a couple of changes and let it mature a bit, and then we can make some sort of grand plan.
looo
Posts: 2898
Joined: Mon Nov 11, 2013 5:29 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby looo » Sat Nov 09, 2019 4:16 pm

vocx wrote:
Fri Nov 08, 2019 4:32 pm
Yes, although it's still a bit premature, I think. I personally don't want to see FreeCAD rushed to 1.0 any time soon. I think we should make a couple of changes and let it mature a bit, and then we can make some sort of grand plan.
For sure this is the only way to get towards 1.0 ;) But making a clear proposal regarding the future of workbenches and modules will help to see what's necessary/possible. I started with a draft of what an automatic porting-tool (without introducing backward incompatibility) needs to provide. Not sure if it is yet complete:
https://github.com/looooo/freecad.pytho ... porting.md
please help with my conda-packaging efforts: https://liberapay.com/looooo/
looo
Posts: 2898
Joined: Mon Nov 11, 2013 5:29 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby looo » Sat Nov 09, 2019 5:29 pm

testing this a little bit I see another problem with the draft workbench: names with underscore like _DraftObjects are used in some places. But this won't work with "from Draft import *". Not sure if this is an issue. when doing a full port.
please help with my conda-packaging efforts: https://liberapay.com/looooo/
vocx
Posts: 1590
Joined: Thu Oct 18, 2018 9:18 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby vocx » Sat Nov 09, 2019 6:56 pm

looo wrote:
Sat Nov 09, 2019 5:29 pm
testing this a little bit I see another problem with the draft workbench: names with underscore like _DraftObjects are used in some places. But this won't work with "from Draft import *". Not sure if this is an issue. when doing a full port.
Yes, it was probably an unfortunate design decision, but I think it can be solved with some aliases, like

Code: Select all

DraftObjects = _DraftObjects
Then I think it should work.

This is precisely what I'm testing at the moment. But I'm doing it quite slowly because I don't want to outright break compatibility. I'm doing some tests, trying to move things to submodules, so that it's easier to handle, not only by me, but by other developers.
looo
Posts: 2898
Joined: Mon Nov 11, 2013 5:29 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby looo » Sat Nov 09, 2019 11:46 pm

vocx wrote:
Sat Nov 09, 2019 6:56 pm
DraftObjects = _DraftObjects
Not sure if this will work all of the time. I guess it's possible there is a DraftObject already defined.

But this is not a problem if we switch all imports for the modules in the namespace package pointing to the namespace package and not to the deprecated old package... But reworking import statements is really a pain. I tried with regex, but there a quite some special cases. Maybe there is a python tool available to do this in an automated way.

Here is a first test to automate the creation of the namespace-package, but still a lot is missing. Also I don't think doing everything in an automated way will work (porting of cmake-files, ...)
https://github.com/looooo/freecad.pytho ... w_style.py
please help with my conda-packaging efforts: https://liberapay.com/looooo/
vocx
Posts: 1590
Joined: Thu Oct 18, 2018 9:18 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby vocx » Sun Nov 10, 2019 1:02 am

looo wrote:
Sat Nov 09, 2019 11:46 pm
... Maybe there is a python tool available to do this in an automated way.
...
Oh, I'm not suggesting doing this in an automated fashion. This has to be done manually to test that everything is correct. And yes, of course it's a pain and slow but I think it's the best way to do it.
looo
Posts: 2898
Joined: Mon Nov 11, 2013 5:29 pm

Re: [Discussion] Splitting Draft tools into their own modules

Postby looo » Sun Nov 10, 2019 3:03 pm

vocx wrote:
Sun Nov 10, 2019 1:02 am
looo wrote:
Sat Nov 09, 2019 11:46 pm
... Maybe there is a python tool available to do this in an automated way.
...
Oh, I'm not suggesting doing this in an automated fashion. This has to be done manually to test that everything is correct. And yes, of course it's a pain and slow but I think it's the best way to do it.
You are right, it's simply not possible to do this in an automated way.

Today I tried to restructure the fem-workbench to the new-style. Some basic tests in gui worked, but there are a lot of special stuff like python imports from c++ side and file-names and so on. This is a monster project and keeping stuff backward compatible is nearly impossible. I guess it's best to postpone the restructuring of internal workbenches although it definitely makes sense to port them to the name-space-packages...
Anyway here is my result (in case anyone wants to push on..) https://github.com/looooo/FreeCAD/commi ... 246a786644
please help with my conda-packaging efforts: https://liberapay.com/looooo/