More pull requests.
* Pull request #3082. It has many small fixes in the import of modules (for example, we avoid from something import *), as well as many edits in Python style to comply with PEP8. This pull request touches many files; I aimed for a single commit per file, so I don't want to squash it; I think this is better to review the commits individually. If it is merged first, pull requests by other authors may need to be rebased. This must be merged after #3097.
* Pull request #3082 has a lower number than #3097 because I originally opened it to test some things in Travis. But now it contains code that follows #3097, so it should be merged after it.
* Pull request #3156. It has various improvements and error checking in the new array functions located in draftobjects/. It must be merged after #3082.
* Pull request #3157. It re-arranges some code of the Draft_SelectPlane command, and its task panel. The Draft_SetWorkingPlaneProxy command is renamed to Draft_WorkingPlaneProxy and is placed in its own module. It is also added to the Draft toolbar for easier access. Previously it was hidden in a menu so many people didn't know about it. It must be merged after #3156.
* Pull request #3158. Small improvements in the task panel code of the new array tools, and also their .ui files. Now the Link array is created by default. Hopefully this way more people can test the App::Link object and report issues. See also Making the creation of arrays more user friendly.
[Discussion] Splitting Draft tools into their own modules
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: [Discussion] Splitting Draft tools into their own modules
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: [Discussion] Splitting Draft tools into their own modules
Penalized is a strong word. It's not a penalty.
No, the task panel doesn't remember this option. I'm not sure how other interfaces do it, but maybe they do it by using a parameter, you know, one of those things you can set in the parameter editor. I thought about this as well, but I didn't implement it.
It's not hard to do, it would basically read a parameter or choose a default value.
Code: Select all
set_param("use_link", True)
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: [Discussion] Splitting Draft tools into their own modules
This is now implemented in #3158.
The checkboxes are initialized with a value from a parameter. If the user toggles the checkbox, the new state is saved, so next time the command is used, the checkbox should remember the previous state.
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: [Discussion] Splitting Draft tools into their own modules
Hello there! Would it be good/possible to have separate folders for base classes modules (guicommandbase, objectbase, viewproviderbase)?
follow my experiments on BIM modelling for architecture design
Re: [Discussion] Splitting Draft tools into their own modules
Yes, of course it would be possible, but what is your idea? Do you mean folders within the current folders?
Code: Select all
draftguitools/
guicommandbase/
draftobjects/
objectbase/
draftviewproviders/
viewproviderbase/
I have a branch were I tentatively move the DraftObject class for all Draft objects in Draft.py, and similarly ViewProviderDraft for their view providers. I haven't worked on that branch for months. After organizing the Gui Commands I will probably return to look into this.
Branch BaseObject.
Last edited by vocx on Wed Apr 08, 2020 10:50 pm, edited 1 time in total.
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: [Discussion] Splitting Draft tools into their own modules
More pull requests.
* Pull request #3182. This moves many commands from DraftTools.py to their individual modules. These are many of the "utility" commands, so they don't depend on the basic DraftTool class, nor the Creator nor Modifier classes. A few new commands, like Draft_Arc_3Points, are also in this group.
* Pull request #3291. This moves the basic classes DraftTool, Creator, and Modifier from DraftTools.py to a new module gui_base_original.py.
* Pull request #3299. This moves all "Creator" commands, that is, those that depend on the Creator class, from DraftTools.py to individual modules.
* Pull request #3308. This moves all "Modifier" commands, that is, those that depend on the Modifier class, from DraftTools.py to individual modules.
At this point in time, #3308 is still incomplete, as I am still adding commits, that is, moving commands. There are many commits, but hopefully they are easy to review as it's normally one commit per command.
* Pull request #3182. This moves many commands from DraftTools.py to their individual modules. These are many of the "utility" commands, so they don't depend on the basic DraftTool class, nor the Creator nor Modifier classes. A few new commands, like Draft_Arc_3Points, are also in this group.
* Pull request #3291. This moves the basic classes DraftTool, Creator, and Modifier from DraftTools.py to a new module gui_base_original.py.
* Pull request #3299. This moves all "Creator" commands, that is, those that depend on the Creator class, from DraftTools.py to individual modules.
* Pull request #3308. This moves all "Modifier" commands, that is, those that depend on the Modifier class, from DraftTools.py to individual modules.
At this point in time, #3308 is still incomplete, as I am still adding commits, that is, moving commands. There are many commits, but hopefully they are easy to review as it's normally one commit per command.
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: [Discussion] Splitting Draft tools into their own modules
My last pull request is #3344 which makes sure the code is compatible with Python 2, by using the correct syntax of super() for this version.
My pull requests so far have moved a ton of graphical code, Gui Commands and task panels, which shouldn't affect the underlying scripted objects that are created with the Draft Workbench.
The reorganization is summarized in pull request #2429.
Currently Carlo is trying to split the object code, in pull requests #3367, #3388. Since this is hard, possibly he will open more pull requests, and refactor the existing ones. This is shaping nicely and it's the kind of organization that I would like to see in all Python based workbenches. I hope we can make it some sort of standard, subject to discussion with other workbenches like Path and FEM.
Also, although I have focused on Draft, I see the re-organization also happening in Arch. Doing it for Arch should be simpler, as the code is more organized to start, and also we have more experience identifying the tricky parts.
My pull requests so far have moved a ton of graphical code, Gui Commands and task panels, which shouldn't affect the underlying scripted objects that are created with the Draft Workbench.
The reorganization is summarized in pull request #2429.
Currently Carlo is trying to split the object code, in pull requests #3367, #3388. Since this is hard, possibly he will open more pull requests, and refactor the existing ones. This is shaping nicely and it's the kind of organization that I would like to see in all Python based workbenches. I hope we can make it some sort of standard, subject to discussion with other workbenches like Path and FEM.
Also, although I have focused on Draft, I see the re-organization also happening in Arch. Doing it for Arch should be simpler, as the code is more organized to start, and also we have more experience identifying the tricky parts.
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.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Re: [Discussion] Splitting Draft tools into their own modules
Is there a schematics somewhere where you explain how this new code should be organised ? Did you start the "discussion with other workbenches" already ? Shouldn't this wait for after FreeCAD v0.19 is released ?
Re: [Discussion] Splitting Draft tools into their own modules
I see what you guys are doing as a really good experiment. I have my doubts about extending this to other workbenches TBH, because it also grew very complex with many, many files and folders, where one single functionality is spread over many different files.
This is of course a million times better than how it was before, all in one file or so
but other workbenches are usually much better organized, with already everything about one thing in one file.
I guess it has to do with the nature of Draft mostly, which is a highly complex thing full with interactions..
One thing i'd like to do in Arch is separate better the "base" (archcommands and archcomponent) from the rest (there is redundant stuff there too), also move importers/exporters in a subfolder)
This is of course a million times better than how it was before, all in one file or so
but other workbenches are usually much better organized, with already everything about one thing in one file.I guess it has to do with the nature of Draft mostly, which is a highly complex thing full with interactions..
One thing i'd like to do in Arch is separate better the "base" (archcommands and archcomponent) from the rest (there is redundant stuff there too), also move importers/exporters in a subfolder)