Skip to content
This repository has been archived by the owner on Oct 2, 2020. It is now read-only.

Keyboard footprint merge discussion #2416

Open
perigoso opened this issue Aug 25, 2020 · 19 comments
Open

Keyboard footprint merge discussion #2416

perigoso opened this issue Aug 25, 2020 · 19 comments

Comments

@perigoso
Copy link
Contributor

perigoso commented Aug 25, 2020

I'm creating this issue to have a centralized place for discussion regarding the massive keyboard footprints merge that i now split into multiple PRs.

This way we have somewhere to discuss things that affect all the fp's and we can better coordinate things.

The original PR #2394

Alps/Matias PR #2417
Cherry MX PR #2418
Cherry MX / Alps / Matias hybrid PR #2419
Kailh Choc PR #2420
Kailh HS socket #2421

@perigoso
Copy link
Contributor Author

perigoso commented Aug 25, 2020

The original Button_Switch_Keyboard.pretty Includes a README.md, is this required? What's it's purpose? It seems most footprint libs don't include this file.

@diegoherranz
Copy link
Collaborator

The original Button_Switch_Keyboard.pretty Includes a README.md, is this required? What's it's purpose? It seems most footprint libs don't include this file.

No. In fact, I would remove it. It may come from the old repo structure in which every .pretty was a separate repo.

@perigoso
Copy link
Contributor Author

perigoso commented Aug 26, 2020

In that case maybe we'd remove it from all libs that include one? can I submit a PR with that or Just for the Button_Switch_Keyboard.pretty lib, since it would be the last file in that folder after the keyboard switch PRs move things around.

@perigoso
Copy link
Contributor Author

So I had _NoSilk variants of footprints, because some people, including me, don't include silkscreen on the switch footprints for aesthetic reasons, but i was unaware that it was possible to hide it in bulk in pcbnew, so after some digging around and trying things out i came to this:

image

This is a good versatile solution, and i feel the _NoSilk variants don't make sense given this option, maybe it might not be immediately clear to people but still, any input?

@evanshultz
Copy link
Collaborator

We require assets to comply with http://kicad-pcb.org/libraries/klc/, unless there's a specific reason not to or that doc needs an update. In this case, it's not. So yes, please only keep versions with silk as those do comply with the library guidelines.

@perigoso
Copy link
Contributor Author

I am familiar with KLC, I see no reason the _NoSilk versions of the footprints do not comply, hence why i was ok with including them in the first place.

@chschlue
Copy link
Contributor

@perigoso
Copy link
Contributor Author

perigoso commented Aug 27, 2020

The reference was still included, they just didn't have the square outline, and I don't see anything about that being required, maybe that should be included there if that is the case.

@chschlue
Copy link
Contributor

chschlue commented Aug 27, 2020

Yes, if you want to be really, really finnicky about the wording, you could argue that outline silk is not explicitly required.

But a silk pin 1 designator sure is. Please also add outline silk while you're at it ;)

@perigoso
Copy link
Contributor Author

I was not trying to word things my way, i was genuinely under the impression it was not required TIL i guess. I knew about the pin 1 marker but these footprints are not polarized, and they can only be mounted one way anyway.

I believe the hybrid footprints don't have a silkscreen outline, so I'll add it to those too.

@chschlue
Copy link
Contributor

Sry, got you wrong there.

But as you said, users can always disable it if they don't like it.

@perigoso
Copy link
Contributor Author

In that case maybe we'd remove it from all libs that include one? can I submit a PR with that or Just for the Button_Switch_Keyboard.pretty lib, since it would be the last file in that folder after the keyboard switch PRs move things around.

What about this? the question got buried.

@chschlue
Copy link
Contributor

Please stick to the switches for now.
Some amount of restructuring for v6 is coming and I would like some structure in "housekeeping" PRs like that if possible.

@perigoso
Copy link
Contributor Author

Thinking these footprints are a good candidate for a script with kicad-footprint-generator, should've come to this realization before having done all this manual work

@perigoso
Copy link
Contributor Author

perigoso commented Sep 4, 2020

Created Scripts for the generation of these footprints

@perigoso
Copy link
Contributor Author

perigoso commented Sep 4, 2020

Created a PR pointhi/kicad-footprint-generator#605 with the scripts to generate keyboard switch footprints, the PRs have been updated with the generated footprints, for reference here are the footprints:

image
image
image
image
image
image

@perigoso
Copy link
Contributor Author

perigoso commented Sep 4, 2020

Of note, I removed the stabilizer mounting holes from these footprints, i intend to add them in separate footprints.

@perigoso
Copy link
Contributor Author

perigoso commented Sep 4, 2020

There are some issues on the scripts that need to be fixed, namely 3D model settings, and reference designation.

@perigoso
Copy link
Contributor Author

Some issues on the script have been fixed and the footprints re-generated.

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

No branches or pull requests

4 participants