Making the creation of arrays more user friendly

[vocx]

...
So this means that having some sort of preview of the array will not be possible?...

It may work, depending on how it is implemented. If you take a look at the Draft tools, for wire, rectangle, polygon, spline, etc., many of them show previews of the resulting objects. These previews are called "trackers" and are defined in the DraftTracker.py file. So, when a tool is started, that tool also starts the corresponding tracker to produce a preview. These trackers are generated in the 3D view itself by using the Coin library (pivy). This is the reason most of the tools in Draft aren't called directly but use that delayed mechanism.

Basically, what you would have to do is prepare a tracker for the array, that is, create the array using the Coin library, and once the inputs are correct in your task panel, remove the tracker, and produce the real geometry (the Array object with the delayed execution of the makeArray function).

[alonso_jamm]

Basically, what you would have to do is prepare a tracker for the array, that is, create the array using the Coin library, and once the inputs are correct in your task panel, remove the tracker, and produce the real geometry (the Array object with the delayed execution of the makeArray function).

Thanks! I will look at the the trackers in the Draft workbench.

I have seen your implementation of the polarArray task. I like it; however, I wonder if you would like to have a QLineEdit where the name of the selected basis for the array should be displayed (similar to what I did in my macro). Also, I think we could solve the problem of having too few elements in the polarArray (less than 2) by simply setting a minimum value of 2 to the spin box.

[vocx]

Thanks! I will look at the the trackers in the Draft workbench.

I quickly looked at your implementation again, and I think that you show the preview by pressing a button and basically building the array in place. Then you remove it and build the real object, right?

The preview is fine like this if it works for you. Using Coin is just for convenience because Coin doesn't create more "objects" inside the document; it is just manipulation of the 3D view itself, which is supposed to be faster.

I have seen your implementation of the polarArray task. I like it; however, I wonder if you would like to have a QLineEdit where the name of the selected basis for the array should be displayed (similar to what I did in my macro).

Yes, sounds good. I know there is room for improvement. But before doing that, I wanted to have the directory structure set up, and something that really works without crashing.

Also, I think we could solve the problem of having too few elements in the polarArray (less than 2) by simply setting a minimum value of 2 to the spin box.

Yes, this sounds good. I think I was trying different things to handle exceptions and test my code, but sure we can improve everything.

[alonso_jamm]

The preview is fine like this if it works for you. Using Coin is just for convenience because Coin doesn't create more "objects" inside the document; it is just manipulation of the 3D view itself, which is supposed to be faster.

My implementation was the easiest for me since I never did anything directly with the view providers; however, I want to help with the Draft workbench and I think that using Coin would be better for making my code as similar to the one used in the workbench. And learning how to use Coin may be helpful in the future

Yes, sounds good. I know there is room for improvement. But before doing that, I wanted to have the directory structure set up, and something that really works without crashing.

I like the new structure, I feel it is more intuitive. Like I said I would like to help; however, I don't know which branch should I use as a basis.

[vocx]

...
I like the new structure, I feel it is more intuitive. Like I said I would like to help; however, I don't know which branch should I use as a basis.

I want to submit the pull requests soon. I've just gotten sidetracked with some things.

Try using CircularArray as base. Just look at the structure of it. PolarArray has basically the same structure, so they could be merged in any order.

However, I am trying to merge them in this order: GuiCommand_base, then PolarArray, then CircularArray.

I didn't want to touch the Rectangular Array tool because this one is the original tool, so I prefer to work on newer functionality that adds to the program in 0.19. Going back to the rectangular array tool is good, but we would be modifying something that already exists, and we have to be careful on this to avoid breaking backwards compatibility.

[vocx]

...
I like the new structure, I feel it is more intuitive. Like I said I would like to help; however, I don't know which branch should I use as a basis.

Okay, I have submitted the new structure and new tools.

Pull requests #2823, #2824, #2825, which should be merged in that order.

[Gift]

Hello busy bee (vocx),

I observe your work on the draft module. The code splitting is a necessary measure. Some questions:
1. How solve you the compatibility when you splitting the array types to old freecad files?
2. Will the class _Array stay in Draft.py?
3. Is alteration in the test unit projected?

The bug of polar array affects probably CircularArray & PathArray.

[vocx]

Hello busy bee (vocx),

I observe your work on the draft module. The code splitting is a necessary measure. Some questions:
1. How solve you the compatibility when you splitting the array types to old freecad files?
2. Will the class _Array stay in Draft.py?

At the moment I will not split the _Array class because older files won't find the corresponding Proxy class, so they will fail to load. So, I need to look very well at this and think about how to do it.

I think we can think of a dummy class _Array, which tests whether the array is rectangular, polar, or circular, and direct them to specific classes _ArrayRectangular, _ArrayPolar, _ArrayCircular.

The _Array class, as well as all other classes in Draft.py, should be moved to individual modules inside Draft/draftobjects/ in the new structure. However, again, I need to think how to do this properly to avoid breaking older files.

So, currently, I'm trying to set up the structure, little by little. Once the structure is set, then we can make some tests.

3. Is alteration in the test unit projected?

Whenever you change the code, you should run the unit tests to find problems in your code. If you find a problem, then you should investigate, and possibly modify the unit tests to match the new code. Currently the tests only use makeArray(). In the future, they could use make_rectangular_array(), make_polar_array(), make_circular_array().

The bug of polar array affects probably CircularArray & PathArray.

The Draft_PolarArray and Draft_CircularArray tools just use makeArray(), but they don't change it. So, if you modify this function, the former two Gui Commands will be updated transparently.

I believe Draft_PathArray does not depend on makeArray(); it's a separate implementation makePathArray(). So it is not affected by whatever you did to makeArray().

[yorik]

Excellent stuff @alonso_jamm! I really liked that it's not much "weight" on top of the existing tool (I would indeed try to allow it to check if an object is already selected when launching the tool. That way, it's just one click more than the existing implementation.

[vocx]

...
I like the new structure, I feel it is more intuitive. Like I said I would like to help; however, I don't know which branch should I use as a basis.

Draft_PolarArray and Draft_CircularArray are now part of the master code. I think they work reasonably well. You can check the code in draftguitools/ and drafttaskpanels/ to see the implementation.

They have additional code that is not used at the moment. For example, the 3D view does not trap the key presses of X, Y, Z. This was taken from DraftGui.py. Most Draft tools trap the keypresses in order to match the specific coordinate with the corresponding Gui::InputField in the .ui file.

Yorik, any trick to create a preview? We can do it like alonso, and just create a temporary object (Part_Feature) that becomes the final Array if accepted. Or we could create the preview objects entirely in Coin, or not?