[Discussion] Splitting Draft tools into their own modules

[carlopav]

lol...
Edit: Please Triplus, be serious... what do you propose?

[triplus]

lol...
Edit: Please Triplus, be serious... what do you propose?

In short cut the Draft module folder from the Mod location and paste it into Ext/freecad location and start from there. Note that i don't necessarily propose that, but that would need to happen, if we want to say draft module has migrated to being a namespace module. The current work being done isn't all that related.

On what i am proposing, if the above won't happen anytime soon, is to keep the Draft module in Mod folder location and to put draft API oriented .py files inside the Ext/freecad location.

[carlopav]

thanks for the explanation, i let the others reply, since i do not have enough knowledge on this topic to have an opinion on that.

[vocx]

...
I feel that current Draft module restructuring really isn't all that much related to "namespace modules". It is more about making code more maintainable and pep8 compatible
...

...if we want to say draft module has migrated to being a namespace module.

Nobody ever mentioned migrating Draft to be a namespace workbench. I don't understand why you even bring this up.

The primary objective of this thread was to improve the maintainability of the Draft codebase, because this codebase was massive and concentrated in only a few, hard to read, hard to modify modules. Basically, we wanted Draft to be more like Arch, FEM, and Path, which are more structured.

The public interface of Draft is the Draft.py module. That's it. You don't need to do anything else but import this module.

Code: Select all

import Draft

Draft.make_line(...)

Yes, we could migrate Draft to be a namespace workbench, but just like the past 8 months, that would require a lot of work, and heavy testing to make sure the code doesn't break. It's a lot of work. I have thought about it but it's definitely not a priority at the moment; the priority is to improve the Draft codebase, add documentation strings, clean up the style (PEP8), fix bugs, and add new desired functionality.

If you want to test your proposal you could essentially copy Draft.py, and place it in freecad/draft.py, and test it that way. But that is definitely not a priority. There are tons of functions that use the Draft namespace, which would need to be changed to freecad.draft, not only in the Draft workbench itself but in Arch, BIM, and a few other external workbenches.

I mean, why do you want to have Draft as installable through Pip? Draft is part of the standard system, so it does not make much sense to install it through Pip. The namespace workbenches make a lot of sense when talking about external workbenches, but for internal workbenches they can remain as they are right now. Migrating Draft to a namespace workbench could happen, but not in the foreseeable future.

[triplus]

I likely wouldn't move Draft.py to Ext/FreeCAD, due to preserving backward compatibility. Doing that would likely only make sense, if the whole module would get ported. Then likely it would be the other way around. The need to preserve some sort of backward compatibility in Draft.py, leveraging the new draft API. Hence, as said, without porting the whole module, what could be done, is to create a draft API there, leveraging Draft.py. You often talk on how you care about having a well defined, document and tested API. Other developers (lately) mostly talk about desire to have a Pythonic API. This is therefore one possible solution to have that. As for on how only external modules should care about being namespace modules. I have been involved in such discussions from the beginning and i don't feel that is the ultimate goal. In other threads some people have already started marking modules as Draft with the term legacy. Providing default set of modules as legacy and external ones as "standard" FreeCAD modules, well ...

P.S. Anyway, i just shared my thoughts, as i am currently working on accessories menu and have both variants working. This was my first developer oriented experience with Ext modules. Due to the dynamics and people expectations, likely i will end up selecting the Ext option.

[vocx]

Updated description of the Draft Workbench. A summary of the reorganization effort is in pull request #2429.

Draft_architecture_v2.png (677.5 KiB) Viewed 387 times

Simplified description as follows.

Essentially, it's like a funnel. The objects and viewproviders are the basic building blocks of the workbench. A new object is created through the make functions, which are imported into the "Draft" namespace, from which they can be used in scripts and other workbenches. This should be the public programming interface (API).

The Draft functions can be used graphically (buttons and menus) through the workbench's GuiCommands, defined in the draftguitools submodules. Importing "DraftTools" is sufficient to register all such GuiCommands in FreeCAD, and then they can be used in other workbenches.

Draft_architecture_simplified_v2.png (40.49 KiB) Viewed 387 times

Draft_architecture_v2.svg

(127.01 KiB) Downloaded 8 times

Draft_architecture_simplified_v2.svg

(52.43 KiB) Downloaded 8 times

[Kunda1]

Congrats on job well done, @vocx and all other involved.

[Zolko]

A new object is created through the make functions, which are imported into the "Draft" namespace, from which they can be used in scripts and other workbenches. This should be the public programming interface (API) .... and then they can be used in other workbenches.

As a concrete example, if another workbench wanted to use the Draft polar array objects and GUI, what would the code look like ?

[vocx]

As a concrete example, if another workbench wanted to use the Draft polar array objects and GUI, what would the code look like ?

Draft PolarArray

Code: Select all

import Draft

array = Draft.make_polar_array(my_object, 8, 270, App.Vector(-1600, 0, 0))
App.ActiveDocument.recompute()

The GUI is a bit more special because the GUI commands aren't intended to be scripted. You can load the tools of the Draft Workbench, and then you can add them to your own toolbars in your own workbench's InitGui.py.

Code: Select all

class MyWorkbench:
    def Initialize(self):
        import DraftTools
        self.appendToolbar("Draft tools", "Draft_PolarArray")

I already showed how to do it for Assembly4.

https://github.com/Zolko-123/FreeCAD_Assembly4/pull/59

However, what would be interesting is to be able to properly subclass "Draft_PolarArray"; in order to do this well, this command should be extended in a few ways, but I haven't tested my ideas as described in this thread, change default transparency of rectangle in Draft.

[Zolko]

As a concrete example, if another workbench wanted to use the Draft polar array objects and GUI, what would the code look like ?

Code: Select all

import Draft
...

I need to import the entire Draft workbench only to use 1 Draft object (importing directly draftobjects/polararray.py also imports the entire Draft WB). The code for polar arrays is spread over 5 files in 5 directories.

How this is supposed to make life simpler for anyone is beyond my understanding.