alonso_jamm wrote: ↑Thu Dec 19, 2019 7:25 pm
...
This macro is only for rectangular arrays, but I wanted to first get feedback on this macro before trying to make similar Tasks for creating the other types of arrays.
It's good. I have the same idea. I already created a few branches to launch the CircularArray and the PolarArray tools, but I haven't submitted a pull request.
I haven't submitted my code for the simple reason that before submitting it I wanted to structure more the code so that it is not messy. The
Draft Workbench is a pretty old workbench, started around 2009; therefore it has a lot of baggage that it has accumulated over the years. So instead of just adding more code to only a few files (Draft.py, DraftGui.py, and DraftTools.py are huge!), I thought it would be good to do things in a planned way.
Please read about it here
[Discussion] Splitting Draft tools into their own modules.
Basically, I want to separate the code into graphical parts (the
task panel and view providers) from the implementation (the GuiCommand classes, and the underlying functions, essentially
Draft.makeArray).
See my branch
GuiCommand_base. This sets up the needed directories for putting new commands.
Once you have merged that, then you can merge the
PolarArray and
CircularArray branches, where the new commands are implemented.
I noticed that in your implementation you used some observers. I haven't investigated that, so I didn't do that in my code. Maybe you can take a look at my code so that you get some ideas. It would be good if you structured your code in a similar way to mine. Why did I do it this way? Because ideally we can split all graphical commands inside DraftTools.py into their own individual modules, so that they are easier to manage and extend.
All graphical commands in Draft (all the buttons that you see) are defined in DraftTools.py and are based on some parent classes that set up some things in the interface (DraftGui.py) this is all connected and it's not very easy to untangle, so that's why I'm proceeding slowly, trying not to break backwards compatibility. Maybe we will have to break compatibility at some point, but we should avoid that if possible at the beginning.
I'll make a few changes to my code and submit it shortly. As long as it's graphical commands (buttons) changing them is not that hard. The problem is changing the underlying commands inside Draft.py. These are more critical.