[Discussion] Splitting Draft tools into their own modules

[Joel_graff]

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.

[vocx]

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]

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

[looo]

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.

[vocx]

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]

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

[vocx]

... 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]

... 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

[vocx]

An update on the organization tasks.

* Pull request #2823. GuiCommandBase class to support all commands. It's basically the same as DraftTool.DraftTool.
* Pull request #2824. Draft_PolarArray using this new structure.
* Pull request #2825. Draft_CircularArray using this new structure. Also see Making the creation of arrays more user friendly.

Moving small functions to their own modules helps us keep Draft.py and DraftGui.py smaller.
* Pull request #2829. Moving some utilities to a separate module.
* Pull request #2830. Moving some GUI utilities to a separate module.
* Pull request #2831. Moving the "todo" class to a separate module.
* Pull request #2832. Moving the "translate" function to a separate module.

[vocx]

Currently pull request #2829 and above are failing the Travis tests.

The problem is a bit strange. The new package draftutils is not being found.

https://travis-ci.org/FreeCAD/FreeCAD/j ... 9909-L9913

Code: Select all

  File "/usr/local/Mod/Fem/femexamples/thermomech_flow1d.py", line 76, in setup
    from Draft import makeWire
  File "/usr/local/Mod/Draft/Draft.py", line 84, in <module>
    import draftutils.utils
ModuleNotFoundError: No module named 'draftutils'

This error is produced when the FEM tests and Path tests are run. It seems FEM creates some Draft geometry like wires, and Path uses Arch Panel, which internally uses Draft.

However, these tests work without problem in my system.

The cause of the error seems to be that the new modules (files) are not being placed in the correct directory when the compiled software is installed.

https://travis-ci.org/FreeCAD/FreeCAD/j ... 7781-L7833

For example, the test files and the new utility files should be in their respective subdirectories drafttests/ and draftutils/. However, Travis puts them all under the root Mod/Draft directory.

Incorrect:

Code: Select all

-- Installing: /usr/local/Mod/Draft/__init__.py
-- Installing: /usr/local/Mod/Draft/auxiliary.py
-- Installing: /usr/local/Mod/Draft/test_import.py
-- Installing: /usr/local/Mod/Draft/test_import_gui.py
-- Installing: /usr/local/Mod/Draft/test_import_tools.py
-- Installing: /usr/local/Mod/Draft/test_pivy.py
-- Installing: /usr/local/Mod/Draft/test_creation.py
-- Installing: /usr/local/Mod/Draft/test_modification.py
-- Installing: /usr/local/Mod/Draft/test_svg.py
-- Installing: /usr/local/Mod/Draft/test_dxf.py
-- Installing: /usr/local/Mod/Draft/test_dwg.py
-- Installing: /usr/local/Mod/Draft/test_oca.py
-- Installing: /usr/local/Mod/Draft/test_airfoildat.py
-- Installing: /usr/local/Mod/Draft/__init__.py
-- Installing: /usr/local/Mod/Draft/utils.py

Correct:

Code: Select all

-- Installing: /usr/local/Mod/Draft/drafttests/__init__.py
-- Installing: /usr/local/Mod/Draft/drafttests/auxiliary.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_import.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_import_gui.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_import_tools.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_pivy.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_creation.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_modification.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_svg.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_dxf.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_dwg.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_oca.py
-- Installing: /usr/local/Mod/Draft/drafttests/test_airfoildat.py
-- Installing: /usr/local/Mod/Draft/draftutils/__init__.py
-- Installing: /usr/local/Mod/Draft/draftutils/utils.py

As I said, this error happens only in Travis. If you get the source code of the branch and compile it locally, the correct directories are created, and the modules are found.

----

It seems that since pull request #2727, git commit fa73d29d, the Travis system puts the new files at the top level directory Mod/Draft/ instead of creating a subdirectory Mod/Draft/draftests/. Does anybody know why this happens?

See: https://travis-ci.org/FreeCAD/FreeCAD/j ... 7418-L7430

This also occurs in the freecad-daily package.

Code: Select all

ls -l /usr/share/freecad-daily/Mod/Draft/
total 14240
-rw-r--r-- 1 root root     3158 Dec 26 08:05 auxiliary.py
-rw-r--r-- 1 root root    60703 Dec 26 08:05 DraftEdit.py
-rw-r--r-- 1 root root    11860 Dec 26 08:05 DraftFillet.py
-rw-r--r-- 1 root root   115679 Dec 26 08:05 DraftGeomUtils.py
-rw-r--r-- 1 root root   114447 Dec 26 08:05 DraftGui.py
-rw-r--r-- 1 root root    16519 Dec 26 08:05 DraftLayer.py
-rw-r--r-- 1 root root   311286 Dec 26 08:05 Draft.py
-rw-r--r-- 1 root root 13040957 Dec 26 08:06 Draft_rc.py
-rw-r--r-- 1 root root    21075 Dec 26 08:05 DraftSelectPlane.py
-rw-r--r-- 1 root root    67174 Dec 26 08:05 DraftSnap.py
-rw-r--r-- 1 root root   257097 Dec 26 08:05 DraftTools.py
-rw-r--r-- 1 root root    43905 Dec 26 08:05 DraftTrackers.py
-rw-r--r-- 1 root root    23489 Dec 26 08:05 DraftVecUtils.py
-rw-r--r-- 1 root root    41303 Dec 26 08:05 getSVG.py
-rw-r--r-- 1 root root     7418 Dec 26 08:05 importAirfoilDAT.py
-rw-r--r-- 1 root root     8616 Dec 26 08:05 importDWG.py
-rw-r--r-- 1 root root   155035 Dec 26 08:05 importDXF.py
-rw-r--r-- 1 root root    14566 Dec 26 08:05 importOCA.py
-rw-r--r-- 1 root root    74493 Dec 26 08:05 importSVG.py
-rw-r--r-- 1 root root     9354 Dec 26 08:05 InitGui.py
-rw-r--r-- 1 root root        1 Dec 26 08:05 __init__.py
-rw-r--r-- 1 root root     2176 Dec 26 08:05 Init.py
drwxr-xr-x 3 root root     4096 Dec  2 17:59 Resources
-rw-r--r-- 1 root root     4146 Dec 26 08:05 test_airfoildat.py
-rw-r--r-- 1 root root    12460 Dec 26 08:05 test_creation.py
-rw-r--r-- 1 root root     5493 Dec 26 08:05 TestDraft.py
-rw-r--r-- 1 root root     4032 Dec 26 08:05 test_dwg.py
-rw-r--r-- 1 root root     4032 Dec 26 08:05 test_dxf.py
-rw-r--r-- 1 root root     3625 Dec 26 08:05 test_import_gui.py
-rw-r--r-- 1 root root     3105 Dec 26 08:05 test_import.py
-rw-r--r-- 1 root root     3945 Dec 26 08:05 test_import_tools.py
-rw-r--r-- 1 root root    21809 Dec 26 08:05 test_modification.py
-rw-r--r-- 1 root root     4035 Dec 26 08:05 test_oca.py
-rw-r--r-- 1 root root     3646 Dec 26 08:05 test_pivy.py
-rw-r--r-- 1 root root     4030 Dec 26 08:05 test_svg.py
-rw-r--r-- 1 root root    44199 Dec 26 08:05 WorkingPlane.py

The test files are put at the top level instead of being inside Mod/Draft/draftests/.

ping

Do you know why the above happens?

I just checked with FEM's CMakeLists.txt, and in this workbench it seems the modules in subdirectories are installed explicitly.

Code: Select all

INSTALL(FILES ${FemScripts_SRCS} DESTINATION Mod/Fem)
INSTALL(FILES ${FemCommands_SRCS} DESTINATION Mod/Fem/femcommands)
INSTALL(FILES ${FemExamples_SRCS} DESTINATION Mod/Fem/femexamples)
INSTALL(FILES ${FemExampleMeshes_SRCS} DESTINATION Mod/Fem/femexamples/meshes)
etc.

Are the subdirectories like Mod/Draft/draftests/ not created automatically?

In Draft we currently have this

Code: Select all

INSTALL(
    FILES
        ${Draft_SRCS}
        ${Draft_QRC_SRCS}
    DESTINATION
        Mod/Draft
)

Where ${Draft_SRCS} is supposed to have all sources.

So, to fix this it seems I have to add this

Code: Select all

INSTALL(
    FILES
        ${Draft_tests}
    DESTINATION
        Mod/Draft/drafttests
)

However, without this, in my system the directories are created automatically when I build the software. Maybe this works for some situations but not for every situation. It may depend on the version of Cmake perhaps?