[Discussion] Splitting Draft tools into their own modules

[carlopav]

That's also my feeling. I have to work on 4 different modules only when I setup something. All further modifications are 90% carried out on a single module, and it's easier to not have to browse a 2000 lines module...
Perhaps keeping the taskpanel code within the GUI commands could reduce a bit the complexity. But for the rest I really like it...

[Zolko]

I'll bow to the majority if you guys find this absolutely necessary, but I'm more of the same opinion as triplus: neither too much nor too little

that makes it 3 who don't agree (with the new splitting) and 2 who like it.

Indeed! Anyway I think that a bit of cross workbench standardization, being wherever in the middle of this 2 extremes, would help to keep things easily readable.

So, what do other workbenches think of the new Draft code splitting ?

[carlopav]

So, what do other workbenches think of the new Draft code splitting ?

I'd be curious to know...
to me, all my splitting commits can be reversed right now if there is a better shared standard way to do it

Edit: else, i'll continue to organize new tools i'm developing for Arch, in the Draft splitted way...

[bernd]

FEM has splitted years ago! But commands and makes are in one module. But they are rather simple in FEM.

[vocx]

that makes it 3 who don't agree (with the new splitting) and 2 who like it.

You are pushing your own narrative on what others have said. Neither Yorik nor triplus said they don't agree. They said, not too much not too little. Don't extrapolate your feelings because of it.

This is mostly done in the spirit of the FEM workbench which is significantly organized. And it must be; you must always organize code that is large and complex.

[vocx]

...
Perhaps keeping the taskpanel code within the GUI commands could reduce a bit the complexity. But for the rest I really like it...

Well, at the moment, we have this huge DraftGui.py file, so until we can deal with it, and split it apart, we can't organize the taskpanel code inside the Gui Commands. But other than that, yes, we could integrate it. Given that this is runtime code, we can change it without significant problems.

[yorik]

In case of Draft, I agree totally, Draft was a horrible mess where indeed related functionality was split over several modules. But this is not the case of Arch, which IMHO is well organized.

I'd really prefer working on thinning the different components and separating too fat functionality (ex. all the IFC stuff) into submodules than splitting for the sole sake of splitting. But I won't start a war on that... Go ahead and PR if you guys really need it badly

[triplus]

A bit of discussion from here:

https://github.com/FreeCAD/FreeCAD-Enha ... als/pull/6

Combined with my current work on accessories menu. 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 talk about "namespace modules", the very first thing that would need to happen is to move the Draft module from Mod to Ext/freecad location. Some imports and things like that would need to get fixed, and after we could start talking about "namespace modules". If that won't happen anytime soon, what i guess could be done is to "move" Draft API to Ext/freecad location. And to make it as documented and Pythonic, as desired. Things like the FreeCAD convention on consistent usage of C++/Python "method names" to be replaced in favor of pure Python conventions ...

P.S. And obviously to encourage all new development to happen directly in Ext, by only providing documentation on how to do that.

[carlopav]

I probably missed one or two steps ... Can you give a more detailed explanation of what do you propose and which would be the pros (or point to the conversation you are referring)?

[triplus]

I probably missed one or two steps ... Can you give a more detailed explanation of what do you propose and which would be the pros (or point to the conversation you are referring)?

Lets do the cons first. Currently one opens FreeCAD Wiki or downloads/clones FreeCAD source code and looks inside the Mod folder for clues and starts coding. "Oh no", you shouldn't' be doing that! Instead what you should do is to download/clone workbench starter kit and start from there. In addition people have started to nitpick in Pythonic department:

https://wiki.freecadweb.org/Draft_Line

Code: Select all

import FreeCAD as App
import Draft

_doc = App.newDocument()

p1 = App.Vector(0, 0, 0)
p2 = App.Vector(1000, 500, 0)
p3 = App.Vector(-250, -500, 0)
p4 = App.Vector(500, 1000, 0)

Line1 = Draft.makeLine(p1, p2)
Line2 = Draft.makeLine(p3, p4)
_doc.recompute()

"Oh no", i want something like:

Code: Select all

import freecad as app
from freecad.draft import line

_doc = app.new_document()

P1 = app.vector(0, 0, 0)
P2 = app.vector(1000, 500, 0)
P3 = app.vector(-250, -500, 0)
P4 = app.vector(500, 1000, 0)

line_1 = line.make_line(P1, P2)
line_2 = line.make_line(P3, P4)
_doc.recompute()

In addition Draft, or i guess draft, module, should be PIP installable. Then i guess we could say we migrated draft to "namespace module". Or at least its API and leaving the rest in Mod. Pros being all the pros "namespace modules" advertise and cons mentioned above eliminated. As for newly introduced cons. Likely some inconsistency in naming area, between C++/Python and Python API and usually you need to reserve the list for some other items under misc.