Including the scripting part into the kicad library eco system?

[poeschlr]

@easyw from time to time we get people that seem to reinvent the wheel. I fear this is because they do not realize that your cadquerry/freecad scripting tools exist. (Similar problems exist for the footprint generator scripts.)

It might be a good idea to at least include a pointer to the cadquerry directory in the packages3d-source repo. The credits files in the packages3d repo alone do not seem to be enough (New contributors adding new models do not seem to look how the existing models have been created). I am not so sure a note in the Readme will help much. (If you want more time to think about this we can do this in the meantime)

We can include the FCAD_script_generator part as a git submodule. But this would require a fork that only contains this one directory. (Sadly git submodule can not point to subfolders in the source repository. There are unofficial git extensions but i do not assume library contributors would be able to use them.) It would also require that contributors know about git submodule. So maybe not the best option.

Another option would be to "move" that one folder over to the package3d repo. To keep you as maintainer of this little corner, we could give you collaborator status of the kicad-packages3d-source repo. (Of course only as long as you wish to keep maintaining this.) If we choose this option i would try to get the git history across as well.

A third option would be that the kicad team holds a fork of this repo and we point users via the repo description to the fact that your repo is the maintained repo.
I bet we will get pull requests on that fork.
Maybe it is possible to have some automatic script that syncs up the kicad fork with your repo on a regular basis. This would make it easy for contributors to just simply open a new PR on your repo with the same changes. We can even add a note to the pull request template that points to your repo.

[antoniovazquezblanco]

From what I've seen in the repo used for 3d models generation there is a lot of duplicated code. If this is not a critical time task I would try to modularize the scripts to avoid code duplicity. I know that is not an awesome task and right now I cannot contribute to this due to time constraints but this may save time in the future.

CadQuery integration in FreeCad is also not awesome as unless you execute the scripts via command line, CadQuery is not able to use the script folder as the execution path. That is in the way of modularizing the code.

Maybe others can provide more information on the topic as my experience y limited.

Hope this helps!

[poeschlr]

@antoniovazquezblanco This is a different issue and should be discussed somewhere else.

And these scripts are intended to be executed on the command line. (Althought i wrote mine such that they work in both ways. See the Molex, JST and Phoenix connector scripts.)

[easyw]

@poeschlr please have a look at here
KiCad/kicad-packages3D-source#89 (comment)
I have added some thought.

[sethhillbrand]

Hi @easyw

I'm going to raise this again because we are in the process of bringing all aspects of the KiCad distribution into a central location at GitLab. Long-term, we'd like to include/expand some/all of these scripts into a dynamic footprint+model generator built into KiCad.

We're currently looking at placing the scripts part of this repository into its own repository at https://gitlab.com/kicad/libraries. Would you be interested in helping with these projects long-term? If you are interested, we'd like to make you the repository maintainer at GitLab.

My plan to retain the commit history would be to import the repository as-is and then do re-arranging to fit the needed structure as a separate commit on top. Thoughts?

[easyw]

Hi @sethhillbrand
When I started this repository, I did so because there was a strong resistance within the kicad developers to adopt 3d step models instead of the standard ones in the vrml library (you can see this in the kicad forum or in gh discussions).
Since the repository was/is under my control, I didn't have to follow anyone on how to set the rules to create a solid library in terms of mechanical integration... I did it with my vision from my work experience, while discussing it with the kicad library guys, and adopting as 3D modeler FreeCAD which is the most powerful open source 3D tool in the world.
Also this choice was against the kicad developers view, because nobody believed in FreeCAD and instead were suggested solutions with proprietary software.
So far I must say that the choices adopted were not so bad ;)
For these reasons, in order not to have any drift on the quality of the mechanical library and its aesthetic counterpart (wrl), which I have so long pushed and maintained from the beginning even against strong opposition, I would prefer to keep the repository in its current state, simply decentralized from the kicad ecosystem.

[sethhillbrand]

OK, I understand. And thank you for the enormous contributions that you have made!

Do you have any interest in helping as a developer/maintainer for any of the 3d work I described above? I totally understand if not.

[easyw]

@sethhillbrand thanks... you may add me to the repo as collaborator or similar... ATM unfortunately I have very little time to dedicate to kicad, but who knows in the future 😸

[sethhillbrand]

OK! Will do 🤞