[Discussion] Splitting Draft tools into their own modules

A forum dedicated to the Draft, Arch and BIM workbenches development.
carlopav
Posts: 1625
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

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

Postby carlopav » Tue Jun 02, 2020 6:39 am

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...
follow my experiments on BIM modelling for architecture design
User avatar
Zolko
Posts: 1189
Joined: Mon Dec 17, 2018 10:02 am

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

Postby Zolko » Tue Jun 02, 2020 7:49 am

yorik wrote:
Mon May 25, 2020 12:53 pm
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.

carlopav wrote:
Sat May 23, 2020 2:08 pm
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 ?
try the Assembly4 workbench for FreCAD v0.19
install with Tools > Addon Manager > Assembly4 — tutorials here and here
carlopav
Posts: 1625
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

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

Postby carlopav » Tue Jun 02, 2020 8:28 am

Zolko wrote:
Tue Jun 02, 2020 7:49 am
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...
follow my experiments on BIM modelling for architecture design
User avatar
bernd
Posts: 11098
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

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

Postby bernd » Tue Jun 02, 2020 4:22 pm

FEM has splitted years ago! But commands and makes are in one module. But they are rather simple in FEM.
vocx
Posts: 5206
Joined: Thu Oct 18, 2018 9:18 pm

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

Postby vocx » Tue Jun 02, 2020 4:40 pm

Zolko wrote:
Tue Jun 02, 2020 7:49 am
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.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
vocx
Posts: 5206
Joined: Thu Oct 18, 2018 9:18 pm

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

Postby vocx » Tue Jun 02, 2020 4:44 pm

carlopav wrote:
Tue Jun 02, 2020 6:39 am
...
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.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
User avatar
yorik
Site Admin
Posts: 12148
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels, Belgium
Contact:

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

Postby yorik » Wed Jun 03, 2020 3:33 pm

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
Posts: 9475
Joined: Mon Dec 12, 2011 4:45 pm

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

Postby triplus » Mon Jun 15, 2020 9:09 pm

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
Posts: 1625
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

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

Postby carlopav » Mon Jun 15, 2020 9:35 pm

triplus wrote:
Mon Jun 15, 2020 9:09 pm
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)?
follow my experiments on BIM modelling for architecture design
triplus
Posts: 9475
Joined: Mon Dec 12, 2011 4:45 pm

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

Postby triplus » Mon Jun 15, 2020 9:50 pm

carlopav wrote:
Mon Jun 15, 2020 9:35 pm
triplus wrote:
Mon Jun 15, 2020 9:09 pm
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.
Last edited by triplus on Mon Jun 15, 2020 10:00 pm, edited 1 time in total.