Your Priorities for the Draft Workbench

[derek-v-s]

Hi all!

I'd like to use some of my wakefulness to help develop open-source CAD software -- free tools for creators.

I'm familiar with Python, C++, Qt, git, github, wikis, CAD and other design software.

The FreeCAD Draft module interests me, and I'm pleased to see how much Python is involved, since it's my language of choice.

I'm interested in creating tools related to geometric construction, enhancing the user interface and scripting.

While I already have some ideas, which I'll create other threads for, I'm wondering what people are really craving. What are your most desired features or changes for the Draft workbench?

[vocx]

...

I'm interested in creating tools related to geometric construction, enhancing the user interface and scripting.

...

1. I personally think that it's a bit daunting to contribute to Draft because the source files are these huge monolithic modules of 5000 lines of code (Draft.py, DraftGui.py, DraftTools.py, etc.). If you see how the Arch Workbench is written, the code for each object is in a separate module (ArchWindow.py, ArchSite.py, ArchBuildingPart.py, etc.), which are all imported into the main Arch.py file. So maybe you could re-organize the code, and put each individual tool of Draft in a separate module DraftLine.py, DraftBSpline.py, DraftCircle.py, DraftArc.py, etc. This would make it easier to modify existing tools of the workbench, and add new tools.

Looking for an error or a definition in a 5000-line file has its difficulties.

2. Another thing that could be improved is the general documentation of the programming interface, namely the docstrings in each file and function. FreeCAD is supposed to automatically generate documentation with Doxygen. This is in https://www.freecadweb.org/api/ However, it doesn't look particularly good because most functions aren't properly commented. Or maybe the documentation could be done with Sphinx. Do you know the best way to handle documentation of code that is a mix of C++ (most of FreeCAD) and Python (Arch, Draft, BIM, parts of FEM)?

I know these two points aren't "interesting"; they are just about management of the code, but I think they are important, especially as more people want to contribute code to FreeCAD.

3. Otherwise, I guess you can add any drawing tool that exists in Inkscape, LibreCAD, or 2D Autocad, that isn't in Draft. For a long time Draft has had relatively stable tools; but very recently users decided to add new tools like a new Bezier tool (Draft CubicBezCurve) or a new editing mode (Draft Edit Improved).

I think for a very long time Draft has been considered a "basic" 2D drawing set of tools, just good enough to draw basic elements. However, making it more powerful may be interesting to other users.

[FATHI RAMMAH]

i think freecad really,really,really need a construction line command specially draw parallel function

[yorik]

I think as vocx says a blessing would be to put some order in all the mess.. Draft was developed very early in FreeCAD when I barely had began to learn about programming... Also we had problems having many python files at that time, so I tried packaging it all into as few files as possible. It could indeed be split into many more files now.

For me the main thing is that draftsight, the main multiplatform 2D CAD alternative used out there, will stop being free at the end of this year. Which means open-source solutions like libreCAD, QCad and FreeCAD's Draft WB should receive a lot more attention. So this could be an excellent opportunity to level up...

On the list of things I'd like most:

- Add arcs support to the Wire tool, and finally be able to rename it to polyline
- Better trim/extend/join tools. Be able to cut, join, split, separate lines, polylines and other 2D objects with more ease
- Explore new possibilities of DWG support from LibreDWG (which now seems to have gained python bindings), or LibreCAD's new DWG-enabled lib.

In any case, would you decide to work on Draft, that would be awesome!!

[derek-v-s]

So maybe you could re-organize the code, and put each individual tool of Draft in a separate module...

I had the same thought. Having each tool in its own file can also mitigate merge conflicts, and it keeps copyright/authorship more clear. That said, attribution seems like a bit of a problem for splitting up DraftTools (i.e. who wrote what tools?).

We might be able to take it further with the idea of tools as bundled "plugins", which gives people the option to develop and add new tools without touching the source. Although, that's something to talk more about in a dedicated thread, once I have a better understanding of the system.

Do you know the best way to handle documentation of code that is a mix of C++ (most of FreeCAD) and Python (Arch, Draft, BIM, parts of FEM)?

I've never faced that problem before, but I did find:

- https://github.com/Feneric/doxypypy
- https://github.com/michaeljones/breathe

I know these two points aren't "interesting"; they are just about management of the code, but I think they are important, especially as more people want to contribute code to FreeCAD.

Yep. The easier it is to read and understand the code, the easier it is to contribute.

[derek-v-s]

i think freecad really,really,really need a construction line command specially draw parallel function

Hi FATHI RAMMAH :-]

That is also a priority for me.

[derek-v-s]

Hi yorik :-]

I want to start by saying thank you for all the effort you have put into this project. I know the amount of appreciation that volunteer developers receive is often not proportional to the energy spent. Thanks devs!

...we had problems having many python files at that time, so I tried packaging it all into as few files as possible.

Finding the optimal amount of modularity can be tricky, especially in the early days.

For me the main thing is that draftsight, the main multiplatform 2D CAD alternative used out there, will stop being free at the end of this year. Which means open-source solutions like libreCAD, QCad and FreeCAD's Draft WB should receive a lot more attention.

2020 is seemingly going to be a major transitional year.

Regarding your list, are these things you plan to work on? If so, what do you think you would work on first?

[vocx]

I had the same thought. Having each tool in its own file can also mitigate merge conflicts, and it keeps copyright/authorship more clear. That said, attribution seems like a bit of a problem for splitting up DraftTools (i.e. who wrote what tools?).

I don't think you should worry too much about this, as the entire Draft Workbench is basically the product on only one person, Yorik.

Only recently have I seen a couple of people contributing specific tools like Draft Edit Improved or Draft CubicBezCurve.

It doesn't really matter who wrote what at this point, as Yorik is probably the author of 90% of it.

We might be able to take it further with the idea of tools as bundled "plugins", which gives people the option to develop and add new tools without touching the source. Although, that's something to talk more about in a dedicated thread, once I have a better understanding of the system.

This already exists as each workbench is essentially a plugin. You can bundle your code, put it inside .FreeCAD/Mod in your home directory, and you will be adding a new workbench or set of tools to your system without touching the base code.

[derek-v-s]

Thanks vocx! Much to learn, there is.

[yorik]

If you split one file, I would basically just copy over the copyright info of the former file.. Or add yours instead, I have no problem with that really

Basically, to give you a general idea of what I had in mind:

Draft.py contains two things:
- generic functions to be used by python coders, basically to do from python everything you can do via the UI (move, rotate, create line,...)
- definitions of the Draft objects (Line, rectangle...) and their view providers

DraftTools contains the different FreeCAD commands (Line, Rectangle...), that is, basically the "actions" behind the UI buttons. There actions sometimes create objects (Line, Circle..), sometimes not (Move, Rotate..)

DraftGui contains all stuff regarding the UI and the different task panels. It's a mess I'm afraid and almost impossible to split. Probably some parts of it will need to be recoded at some point

There are already other parts that have been split out, like DraftSnap (all the snapping system), DraftTrackers (the 3D screen "widgets" used by draft), DraftVecUtils,DraftGeomUtils,...

I think I would start, like vocx suggests, by splitting DraftTools, by different types of operation: Line, Wire, Rectangle... Then, probably the corresponding function (makeLine) and objects (Line) can also be moved from Draft.py. together. So everything regarding lines is together, and so on... That seems to me an easy way for new people to dig into the code. But if you have better ideas, go ahead!

A couple of things to be aware:

- Everything is always split between GUI and non-GUI use. When using FreeCAD from the command line or as a python module, the FreeCADGui module is not available, neither everything that depends on the UI (view providers, DraftGui, PySide.QtGui,...). You'll see some if FreeCAD.GuiUp here and there that load or don't load stuff appropriately. Basically, the rule is that we should always be able to import Draft in console mode.

- For Draft objects, like all python-defined objects in FreeCAD, the actual code is not stored in a FreeCAD file. Only the module name, class name, and the different properties. When loading a file, a Draft object is reconstructed by creating an object from the module name and class name, and populating its properties. So when loading a file containing a Draft._Line, FreeCAD will try to load a Draft module and create an instance of a _Line class. If we change these things from location or rename them, we must take care of leaving aliases in place.

I haven't really planned to work on any this yet (actually writing the plan above is a good step ). I think I would start with that, as it will make further work much easier... But it's rather boring work, you might prefer to wet the appetite with something more fun