Skip to content
This repository has been archived by the owner on Nov 21, 2017. It is now read-only.

rename to Connectors_WAGO.pretty #1

Closed
pointhi opened this issue Feb 18, 2016 · 9 comments
Closed

rename to Connectors_WAGO.pretty #1

pointhi opened this issue Feb 18, 2016 · 9 comments

Comments

@pointhi
Copy link
Collaborator

pointhi commented Feb 18, 2016

For unification, renaming would be a good idea.

This issue is bounded with: KiCad/TerminalBlock.pretty#6

@evanshultz
Copy link
Collaborator

@pointhi Has this been resolved? I believe the connector libraries have been split and updated since this Issue was created.

@pointhi
Copy link
Collaborator Author

pointhi commented Jun 27, 2017

https://github.com/KiCad/TerminalBlocks_WAGO.pretty is still there, but I don't see a need for it.

@SchrodingersGat what do you think?

@poeschlr
Copy link
Collaborator

poeschlr commented Jun 27, 2017

I think we created two repos recently (TerminalBlocks Wago and Phoenix.)
Why?
We thought that especially the phoenix lib might get too big if we do not split it in any way. (Splitting connectors and terminal blocks seems like a reasonable thing to do.)

Edit: more information:
I think the idea is to split the current terminal block repo into vendor specific repos (First suggestion was to include them in the connectors libs.) Somewhere there is either a pull request or an issue where we decided to create vendor specific libs for terminal blocks. (I currently can't find it)

@pointhi
Copy link
Collaborator Author

pointhi commented Jun 27, 2017

I think that would likely cause confusions for users, at least increase search effort for people not knowing that.

Personally, I think it's a better idea to discuss with the developer about allowing subdirectories, or better grouping of footprints to improve handling of such big repositories.

Like every footprint could have one or more (nested) groups declared in the file format, which are then used in the selection dialog to create parent directories. This should even be backward compatible.

There is not much sense in working around such problems. We should rather fix them.

@evanshultz
Copy link
Collaborator

While we're arguably rather off topic now, I agree with Thomas. Parts that fall into the category of interconnection are in the following libraries:
Connectors* (14 libraries)
Mechanical_Sockets
Modules (that one may a bit of a stretch)
Mounting_Holes
Pin_Headers
Socket_Strips
Sockets
TerminalBlocks* (2 libraries)
Wire_Connections
Wire_Pads

That is 24 libraries that the user could choose from. And they're scattered alphanumerically from C to W.

Let me think out loud about choosing an interconnection. Multiple vendors may have a suitable footprint. Since KiCad has a clear separation between logical (schematic) and physical (PCB), perhaps grouping by manufacturer is wrong. This means more places to look in case the user doesn't care about the vendor but is most interested in finding an interconnect by type/style/pitch/etc.

To me, this is a greater burden. I see a lot of overlap and hunting to find the desired interconnect. While I do like breaking things up a bit and can see how that can be simpler, perhaps a powerful search function is better than having a large number of libraries and only being able to see the contents of one library at a time? Naturally, this would require core developer effort.

And one smaller note. Why is is TerminalBlocks instead of Terminal_Blocks? In every other case I can see, words are separated by underscores or hyphens. This is the only example of CamelCase I see.

@ghost
Copy link

ghost commented Jul 20, 2017

Couple of observations:

  • If we go with vendor-specific repos, is there a minimum number of parts that warrant a repo?
    https://github.com/KiCad/Connectors_Terminal_Blocks.pretty now also contains footprints for 4UCON and Philmore components. The contributor has offered to add more parts from these vendors. It would be nice to sort out the repo structure before they are added.

  • The 3D model folder in kicad-library is named Terminal_Blocks.3dshapes which matches neither the current nor proposed footprint repos.

@SchrodingersGat
Copy link
Contributor

If we go with vendor-specific repos, is there a minimum number of parts that warrant a repo?

Yes, but I don't know what that number is.

The 3D model folder in kicad-library is named Terminal_Blocks.3dshapes which matches neither the current nor proposed footprint repos.

Hmm you're right. The Connectors_Terminal_Blocks library needs reorganization anyhow - the 3D models should get moved at the same time.

@ghost
Copy link

ghost commented Jul 21, 2017

The Connectors_Terminal_Blocks library needs reorganization anyhow - the 3D models should get moved at the same time.

OK, I could open some PRs to do the following ...

  1. Move Phoenix parts from Connectors_Terminal_Blocks.pretty to TerminalBlocks_Phoenix.pretty, fixing the spelling mistake in the footprint names at the same time and updating the 3D paths to match item (4) below.

  2. Move WAGO parts from Connectors_Terminal_Blocks.pretty to TerminalBlocks_WAGO.pretty, updating the 3D paths to match item (4) below.

  3. Rename Connectors_Terminal_Blocks.pretty to TerminalBlocks.pretty to hold the remaining "odds and ends", updating the 3D path to match item (6) below. Q. Should / can this be done by renaming the repo, or is it better to create a new repo, move the parts and mark old repo as deprecated?

  4. Create new 3D model folders TerminalBlocks_Phoenix.3dshapes and TerminalBlocks_WAGO.3dshapes in kicad-library/modules/packages3d.

  5. Move relevant models from Terminal_Blocks.3dshapes to the above folders (fixing spelling mistake in Phoenix parts).

  6. Rename Terminal_Blocks.3dshapes to TerminalBlocks.3dshapes.

Q. Do we choose TerminalBlocks_xxx, Terminal_Blocks_xxx or Terminal-Blocks_xxx?

@pointhi
Copy link
Collaborator Author

pointhi commented Jul 21, 2017

whats the big difference between Connectors and TerminalBlocks to move them into a own naming scheme?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants