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

pretty repositories reorganization #257

Closed
odurc opened this issue Jul 26, 2015 · 34 comments
Closed

pretty repositories reorganization #257

odurc opened this issue Jul 26, 2015 · 34 comments

Comments

@odurc
Copy link
Collaborator

odurc commented Jul 26, 2015

Michal's proposal extension to all pretty repositories, check: KiCad/TO_SOT_Packages_SMD.pretty#1

Check suggestions in this google doc spreadsheet

@michal777
Copy link
Collaborator

I like it! If everybody agree that it's time to make big changes I'm ready to help. I think that the first thing to do is to remove whatever can be removed.

I've also some suggestions/questions/ideas about the table:

Air_Coils_SML_NEOSID.pretty - ok, alternatively may be moved to Inductors_NEOSID.pretty (if will be left)

Capacitors_Elko_ThroughHole.pretty - action 1 is done, this library can be removed (maybe "universal" footprints should be saved).

All Chokes and Inductors - it may be hard to sort them in a wise way because often the same element may be used as choke or not-choke. Inductors is more general name. "Toroids" may be chokes, inductors or transformers.

All four libraries with crystals and oscillators - I'd suggest creating: Crystals.pretty and Oscillators.pretty (without SMD/THT because there is not much content yet)

Displays LCD and LED - I like it but if somebody will add some different type of display there will be problem to classify them. Graphics/7-segm is also bad. Maybe this needs to be discussed. Simplest solution: Displays.pretty

EuroBoard_Outline.pretty - if nobody can prove it's really useful I'm for removing.

Hall-Effect_Transducers_LEM.pretty and PFF_PSF_PSS_Leadforms.pretty - go to new Hall-Effect_Transducers.pretty, it seems to be the same type of current sensing devices

Resistors_Universal.pretty - as was discussed: rename to Universal.pretty and put here more different universal footprints

Oddities.pretty, Wire_Pads.pretty, Wire_Connections_Bridges.pretty - maybe put them into one library, then remove some of footprints or maybe remove at least one library.

Opto-Devices.pretty - I think it should be left

Sockets_BNC.pretty - rename to RF_Connectors to be more general or maybe even "signal_connectors" (maybe needs better name) to include also audio connectors, or "coaxial_connectors" (quite wide class of "analog" connectors)?

Sockets_PGA.pretty - this footprint is in another library so this one should be deleted

Transistors_SMD.pretty - same as Transistors_TO-220.pretty and others (move to TO_SOT_Packages_*)

Socket_Strips.pretty and Pin_Headers.pretty has different 3d models and (in some cases) different pin numbering. I think they can be left as is or put into one library. I'm not sure if adding _THT is necessary. We haven't even smd footprints of this type.

Transistors_OldSowjetAera.pretty, - some new library for rarely used, hard to classify footprints would be usefull but I've no idea how to name it.

Power_Packages_* - to be removed if all my pull requests will be merged.

@odurc
Copy link
Collaborator Author

odurc commented Aug 8, 2015

I moved the table to google doc to keep easy to update. @michal777 I applied some changes you suggested and left some to solve/to discuss.

They are:

  • all choke repos

move all to chokes.pretty or inductors.pretty ?

  • Converters_DCDC_ACDC.pretty

left as is?

  • Filters_HF_Coils_NEOSID.pretty

move to inductors.pretty?

  • Housings_ROHM.pretty

move to ...?

  • IR-DirectFETs.pretty

left as is?

  • Labels.pretty, Symbols.pretty

left as is or or move to only one repo?

  • Measurement_Points.pretty, Measurement_Scales.pretty

left as is or or move to only one repo?

  • Socket_Strips.pretty, Sockets.pretty, Sockets_BNC.pretty, Sockets_Mini-Universal.pretty, Sockets_WAGO734.pretty

move all to sockets.pretty ? move to connectors?

  • Terminal_Blocks.pretty

move to sockets.pretty ? move to connectors? left as is?

  • Transistors_OldSowjetAera.pretty

move to ...?

  • Oddities.pretty, Wire_Connections_Bridges.pretty, Wire_Connections_Bridges.pretty

left as is or or move to only one repo? if one, which name?

@michal777
Copy link
Collaborator

Next post to discussion:

  • all choke repos
    I'd start with creating Inductors_SMD and Inductors_THT and sorting Inductors, Inductors_NEOSID Choke_SMD.pretty;
    Choke_Toroid_ThroughHole - there are inductors and transformers inside so should be either renamed or sorted into inductors, chokes (if will exist) and some transformers library;
    Choke_Common-Mode_Wurth.pretty - I'd remove _Wurth from name - Wurth is in footprints names
    Air_Coils_SML_NEOSID - I'd remove _SML_NEOSID from name - SML and NEOSID are in footprints names
    Choke_Axial_ThroughHole, Choke_Radial_ThroughHole, some of Choke_SMD - I've no idea, it's hard to decide which inductors are chokes, it depends of application
  • Converters_DCDC_ACDC.pretty
    I'd leave it
  • Filters_HF_Coils_NEOSID.pretty
    filters can't go to inductors, if they all are variable maybe can be renamed to filters_inductors_variable
  • Housings_ROHM.pretty
    it's in SMD_Packages, waits for removing
  • IR-DirectFETs.pretty
    I'd leave it or rename to power_mosfets_smd to cover more types of these special high power packages
  • Labels.pretty, Symbols.pretty
    I'd add Measurement_Scales.pretty and put everything in one repo for the graphics items
  • Measurement_Points.pretty, Measurement_Scales.pretty
    to other libraries
  • Socket_Strips.pretty, Sockets.pretty, Sockets_BNC.pretty, Sockets_Mini-Universal.pretty, Sockets_WAGO734.pretty
    If you mix everything the library will be very large;
    the Socket_Strips.pretty and Pin_Headers may be together,
    Sockets.pretty may be left (maybe renamed) for IC and memory sockets (not cables)
    Sockets_BNC.pretty - as I mentioned before - make library for rf or rf+audio connectors
  • Terminal_Blocks.pretty
    I'd leave it
  • Transistors_OldSowjetAera.pretty
    some new library for packages that are not easy to classify - I don't know how to name it
  • Oddities.pretty, Wire_Connections_Bridges.pretty, Wire_Connections_Bridges.pretty (Wire_Pads?)
    I'd add Measurement_Points.pretty and put everything into one repo for pads and bridges

@michal777
Copy link
Collaborator

I've looked into the mess in connectors and sockets. There are following libraries:

  • Connect - includes many types of connectors
  • Connectors_Molex - two types of connectors (wire to board)
  • Mechanical_Sockets - two or three DIN and two non-electrical components
  • Socket_Strips - mostly 2.54 mm
  • Pin_Headers - mostly 2.54 mm
  • Sockets - IC and memory sockets
  • Sockets_BNC - only two BNC
  • Sockets_Mini-Universal - one type of connectors (wire to board)
  • Sockets_MOLEX_KK-System - one type of connectors (wire to board)
  • Sockets_WAGO734 - one type of connectors (wire to board)
  • Terminal_Blocks - two types of terminal blocks

So maybe:

  • Connect -> Connectors - needs cleanup, sockets and terminal blocks to proper libraries
  • Connectors_Molex - leave as is
  • Mechanical_Sockets - move to Connectors, non-electrical parts should be put somewhere else
  • Socket_Strips -> Connectors_Pin_Socket_Strips - allow only these simple 2.54, 2.00 mm
  • Pin_Headers - to Connectors_Pin_Socket_Strips, allow only these simple 2.54, 2.00 mm
  • Sockets - it's ok, needs small cleanup
  • Sockets_BNC - move to Connectors or make library for rf or rf/audio or sth like that
  • Sockets_Mini-Universal -> Connectors_Mini-Universal
  • Sockets_MOLEX_KK-System -> Connectors_MOLEX_KK-System
  • Sockets_WAGO734 - > Connectors_WAGO734
  • Terminal_Blocks -> Connectors_Terminal_Blocks

This way all libraries, apart from Sockets, will start with "Connectors_" and will be together on a alphabetically sorted list of footprints.

@aewallin
Copy link

Update: it seems the confusion arises because new installs of 4.0.0 or 4.0.1 do NOT update the fp-lib-table that resides in a user directory both on Win and Linux installs. A manual update of fp-lib-table fixes the problem. Something for the packaging-team to consider - updating to the latest KiCad now breaks library functionality for many users because of this fp-lib-table issue.

It seems the libraries have been reorganized on github, but the fp-lib-table.for-github file has not been updated!?
This is causing a LOT of confusion as seen now on multiple kicad forums/help-channels. Please could you update fp-lib-table so that it doesn't point to non-existing libraries.
AFAIK this affects the 4.0.0 and 4.0.1 releases and is not a pleasant surprise for non-expert users!
thanks!

@michal777
Copy link
Collaborator

The problem is that bleeding edge users uses fp-lib-table installed with some unstable release instead of their own libraries (off-line or personal github).

@odurc
Copy link
Collaborator Author

odurc commented Jan 4, 2016

I'd like to start doing some changes. Renaming the following repositories:

Buttons_Switches_ThroughHole.pretty -> Buttons_Switches_THT.pretty
Capacitors_ThroughHole.pretty -> Capacitors_THT.pretty
Connect.pretty -> Connectors.pretty
Diodes_ThroughHole.pretty -> Diodes_THT.pretty
Display.pretty -> Displays.pretty
Relays_ThroughHole.pretty -> Relays_THT.pretty
Resistors_ThroughHole.pretty -> Resistors_THT.pretty
Sockets_Mini-Universal.pretty -> Connectors_Mini-Universal.pretty
Sockets_WAGO734.pretty -> Connectors_WAGO734.pretty
Terminal_Blocks.pretty -> Connectors_Terminal_Blocks.pretty

@michal777 and @CarlPoirier can I do this changes now?

@michal777
Copy link
Collaborator

Because of the f#^&@!* kicad github online libraries, removing libraries will cause error messages which are confusing for beginners who suffer from the github fp-lib-table installed by default with some packages/installers of the kicad.
To avoid the problems the old libraries probably must be kept but they may be filled with some placeholder like footprint with a message: "empty library, please remove it from your fp-lib-table" or something like that.

@pointhi
Copy link
Collaborator

pointhi commented Feb 19, 2016

I would link my proposal for connectors cleanup: #368 (comment)

In a nutshell, moving some Sockets_xxx.pretty to vendor specific Connectors_xxx.pretty and renaming the footprints in a scheme like Manufacture_Series_xxx.kicad_mod. So we have only one connector library per manufacture, and the connectors are sorted by series inside it.

@CarlPoirier
Copy link
Collaborator

OK so to put it all together:

Buttons_Switches_ThroughHole.pretty -> Buttons_Switches_THT.pretty
Capacitors_ThroughHole.pretty -> Capacitors_THT.pretty
Connect.pretty -> Connectors.pretty
Diodes_ThroughHole.pretty -> Diodes_THT.pretty
Display.pretty -> Displays.pretty
Relays_ThroughHole.pretty -> Relays_THT.pretty
Resistors_ThroughHole.pretty -> Resistors_THT.pretty
Sockets_Mini-Universal.pretty -> Connectors_Mini-Universal.pretty
Terminal_Blocks.pretty -> Connectors_Terminal_Blocks.pretty
Sockets_BNC.pretty -> Connectors_TE-Connectivity.pretty (KiCad/Connectors_TE-Connectivity.pretty#1)
Sockets_WAGO734.pretty -> Connectors_WAGO.pretty (KiCad/Connectors_WAGO.pretty#1)
Sockets_MOLEX_KK-System.pretty -> Connectors_Molex.pretty (KiCad/Sockets_MOLEX_KK-System.pretty#1)
part of Terminal_Blocks.pretty -> Connectors_WAGO.pretty (KiCad/TerminalBlock.pretty#6)
part of Terminal_Blocks.pretty -> Connectors_Phoenix.pretty (KiCad/TerminalBlock.pretty#6)

A copy of the libraries to be renamed need to be kept in their original state as well for people using fp-lib-table.for-github but not knowing how it works.

@pointhi
Copy link
Collaborator

pointhi commented Feb 20, 2016

@CarlPoirier

  • Terminal_Blocks.pretty -> Connectors_Terminal_Blocks.pretty is not required because of manufacture specific libraries

other suggestions:

  • TO_SOT_Packages_SMD.pretty -> Housings_TO_SOT_SMD.pretty
  • TO_SOT_Packages_THT.pretty -> Housings_TO_SOT_THT.pretty
  • part of SMD_Packages.pretty -> Housings_BGA.pretty
  • part of SMD_Packages.pretty -> Housings_PLCC.pretty
  • part of SMD_Packages.pretty -> Housings_QFP.pretty
  • part of SMD_Packages.pretty -> Housings_SOIC.pretty
  • Wire_Connections_Bridges.pretty -> Wire_Pads.pretty

@CarlPoirier
Copy link
Collaborator

Indeed, no more Terminal_Blocks. As for the TO-SOT, I don't see any benefit of renaming them. Furthermore they are new libraries. SMD_Packages is meant to disappear but we never got to it completely yet! I'm not sure about Wire_Pads.

@anpaza
Copy link

anpaza commented May 3, 2016

One more thing to do is to sort out the path to .3dshapes somehow.

Currently the only place where .3dshapes are found is /usr/share/kicad/modules/packages3d.

It would be good to have something like ${KIPRJMOD} (KIPRJ3DMOD?) but for 3D files, so that projects can use their private .3dshape files. Currently I have to make a link to them to /usr/share/... and this is horrible.

And in general, the .wings files should be excluded from the KiCad distribution. They should be available from the kicad-library repo, just like the .kicad_pcb files with footprints. This Wings3D software is cumbersome and there are little people that can use it, so why copy it to every KiCad user's HDD?

@SchrodingersGat
Copy link
Contributor

@anpaza et al, I think that the 3D files should each have their own repository (e.g. Housings_SSOP.3dshapes becomes a repository). Each .pretty repo gets a matching .3dshapes repo. I think this is a good solution for a few reasons:

  • It does not clutter up the .pretty repositories with mixed file types
  • It gets the 3D models out of the schematic library (strange that they were ever there...)
  • It allows users to pick-and-choose which 3D models they want. Unlike .lib and .kicad_mod files which are tiny, the 3D shapes repository could grow to be very large, and users may want greater fidelity in deciding which 3D files they download
  • The user can download whichever .3dshapes repos they require into a common directory and it would behave just as it would currently.
  • This should all be compatible with the ongoing changes to the way that 3D paths are managed.

@diggit
Copy link
Collaborator

diggit commented May 24, 2016

@anpaza @SchrodingersGat
There were changes in 3D path management. In older versions, path was defined by KISYS3DMOD environment variable which you could easily change. You can set it in KiCAD in Preferences -> Configure Paths, but you have to undefine it in your environment.

In current build (since build 6697, patch here), 3D path is defined separately. AFAIK it is accessible only through footprint 3D settings. There is Configure path button, where you define aliases and paths to directories where are *.3dshapes/ directories located. Then you can use alias:library.3dshapes/model.wrl as filename of model. Unfortunately it is global and if you define some non global alias like ${KIPRJMOD}/3D kicad will inform you about wrong path at projects without 3D subdir.
If you set only 1 alias, it is like substitution of KISYS3DMOD and you don't have to use alias:library.3dshapes/model.wrl, but just library.3dshapes/model.wrl which is current format of all 3d names.

Wings file and even wrl file will be abandoned in future after switching to STEP file format IIRC.

More questions about this topic could be answered through bugreport, here it is OffTopic.

@SchrodingersGat
Copy link
Contributor

Bumping this thread, specifically relating to the inductor / choke repositories.

I currently have a number of PRs outstanding @ https://github.com/KiCad/Inductors.pretty

@anpaza has a very large PR outstanding @ https://github.com/KiCad/Choke_SMD.pretty

Plus, there are the other choke related repositories:

Before these PRs are addressed, I think some action needs to be taken here.

Personally, I would like to see two libraries:

  • Inductors_SMD.pretty
  • Inductors_THT.pretty

and the existing footprints can be migrated to there as required.

What do we all think of this? @CarlPoirier as the man with the power to raise and cull repos, I'm hoping you will weigh in :)

@SchrodingersGat
Copy link
Contributor

If no one has any strong opinions, I would settle for a moderately interested one, even.

What do people think of having two consolidated repositories:

  1. Chokes_Inductors_SMD.pretty
  2. Chokes_Inductors_THT.pretty

@anpaza
Copy link

anpaza commented Jul 14, 2016

That does sound like "oily oil".
I'd say go with "inductors".
The word "inductor" has one and only meaning.
The word "choke" has a completely different primary meaning, and lots of secondary meanings, and it's kind of slang.

@wolfgangbremen
Copy link

I agree with anpaza, that also conforms to michal777.
Another thing that I dislike is the addtion *_.THT to a library name. I assume about 90 % of our elektronic parts are "Through Hole"-parts, so this can be seen as the normal case, whereas SMD-parts are something special. According to michal777: Leave everything not necessary, drop that suspicious THT. Ending up that a library lib1.pretty contains "Through Hole"-parts, and lib1_SMD.pretty is the special one having the analogues parts as SMD-parts.
Above that: Evereyone who knows what kicad is does also know what SMD means, correct? But what is THT? Even an eletronic specialist not knowing kicad will have to guess what that might be. As I work with kicad since years, I know that you mean "Through Hole". But what stands the last "T" for?

@diggit
Copy link
Collaborator

diggit commented Jul 15, 2016

I'd go with Inductors*.lib(s) only. Chokes are special case of inductors.

I made common mistake, it should be _SMT and _THT suffixes.

I agree with @anpaza.

some explanation...

  • SM* - Surface Mount
    • T - technology
    • D - device
  • TH* - Through hole
    • T - technology
    • D - device (never seen used, probably default)

@wolfgangbremen

I assume about 90 % of our elektronic parts are "Through Hole"-parts, so this can be seen as the normal case, whereas SMD-parts are something special.

Umm, what? I don't know what do you mean by our, but eg. 90% of parts on my PCBs are SMD and as THT remains connectors and high power parts only.

@SchrodingersGat
Copy link
Contributor

SMT is by no means "rare" or "special", agreed.

I think the additional "_SMT" suffix adds specificity at the cost of only
four characters and that's a bargain.

/2c

On 16 Jul 2016 3:26 am, "Patrik Bachan" notifications@github.com wrote:

I'd go with Inductors*.lib(s) only. Chokes are special case of inductors.

I made common mistake, it should be _SMT and _THT suffixes.

I agree with @anpaza https://github.com/anpaza.

some explanation...

  • SM* - Surface Mount
    • T - technology
    • D - device
  • TH* - Through hole
    • T - technology
    • D - device (never seen used, probably default)

@wolfgangbremen https://github.com/wolfgangbremen

I assume about 90 % of our elektronic parts are "Through Hole"-parts, so
this can be seen as the normal case, whereas SMD-parts are something
special.

Umm, what? I don't know what do you mean by our, but eg. 90% of parts
on my PCBs are SMD and as THT remains connectors and high power parts only.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#257 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJnQRVGtV02uFh6s119RTXPFXYMTvoQZks5qV6aYgaJpZM4Ff6O1
.

@CarlPoirier
Copy link
Collaborator

CarlPoirier commented Jul 16, 2016

Since changes in libraries cause problems to user who don't know how the fp-lib-table works, we have to keep changes to a minimum. I agree for splitting the Inductors in SMD and THT repos while marking the old one as deprecated. Furthermore, chokes being specific a specific use for inductors, I see no problem in them having their own repository. That being said, the existing choke repositories exist for historical reasons (the easy excuse haha) but indeed could be replaced.

All in all, Inductors_SM*.pretty and Chokes_SM*.pretty would fit the bill.

@anpaza
Copy link

anpaza commented Jul 17, 2016

If chokes are split into a separate library, I expect appearing people opting for splitting power inductors, high-freq inductors etc into separate libraries.
I'd prefer a single library, with KiCad being added a feature (in perspective) to group components in a library by first part(-s?) of the name (delimited by '-') under a [+] expandable subgroup. Thus, if you have something like "Choke-0402", "Choke-0805", "Choke-1206" in "Inductors", they could be all hidden be hind a single [+] and they won't interfere if you don't need them. This should allow to split parts into libraries by families and avoid splitting numerous libraries, often with just a few parts.

P.S. Strange, the site engine replaces "BEHIND" with "BIND", test: behind, be hind, behi nd, mwahaha.

@CarlPoirier
Copy link
Collaborator

The difference with chokes is that they are already split. Also, one thing to keep in mind is that the bigger the .pretty is, the longer it takes to load it from Github.

@SchrodingersGat
Copy link
Contributor

@CarlPoirier have we reached somewhat of an accord on this? If you want to make the appropriate new repositories we can start reassigning parts etc etc :)

@pointhi
Copy link
Collaborator

pointhi commented Oct 1, 2016

@CarlPoirier, @SchrodingersGat , ... It would be cool to get to a conclusion and then start reordering the footprints.

@CarlPoirier
Copy link
Collaborator

CarlPoirier commented Oct 1, 2016

Hi @pointhi,

That's where we were at. Indeed, lets's go ahead. I'll start by merging the pull requests you have already open later this weekend.

Buttons_Switches_ThroughHole.pretty -> Buttons_Switches_THT.pretty
Capacitors_ThroughHole.pretty -> Capacitors_THT.pretty
Connect.pretty -> Connectors.pretty
Diodes_ThroughHole.pretty -> Diodes_THT.pretty
Display.pretty -> Displays.pretty
Relays_ThroughHole.pretty -> Relays_THT.pretty
Resistors_ThroughHole.pretty -> Resistors_THT.pretty
Sockets_Mini-Universal.pretty -> Connectors_Mini-Universal.pretty
Terminal_Blocks.pretty -> Connectors_Terminal_Blocks.pretty
Sockets_BNC.pretty -> Connectors_TE-Connectivity.pretty (KiCad/Connectors_TE-Connectivity.pretty#1)
Sockets_WAGO734.pretty -> Connectors_WAGO.pretty (KiCad/Connectors_WAGO.pretty#1)
Sockets_MOLEX_KK-System.pretty -> Connectors_Molex.pretty (KiCad/Sockets_MOLEX_KK-System.pretty#1)
part of Terminal_Blocks.pretty -> Connectors_WAGO.pretty (KiCad/TerminalBlock.pretty#6)
part of Terminal_Blocks.pretty -> Connectors_Phoenix.pretty (KiCad/TerminalBlock.pretty#6)

Also all of those into Chokes_SMT.pretty and Chokes_THT.pretty:
Choke_Common-Mode_Wurth.pretty
Choke_Toroid_ThroughHole.pretty
Choke_SMD.pretty
Choke_Radial_ThroughHole.pretty
Choke_Axial_ThroughHole.pretty
Air_Coils_SML_NEOSID.pretty

And those into Inductors_SMT.pretty and Inductors_THT.pretty:
Inductors_NEOSID.pretty
Inductors.pretty

@pointhi
Copy link
Collaborator

pointhi commented Oct 1, 2016

For chokes, there are another repositories which also needs to be merged:

@CarlPoirier
Copy link
Collaborator

CarlPoirier commented Oct 1, 2016

Indeed I had not mentioned the Air_Coils_SML_NEOSID.pretty. Also I just noticed that for simple renames, we need not keep the old repo since Github offers repository redirection!

@CarlPoirier
Copy link
Collaborator

I thought the links in the summary were pull requests. You can go ahead and add symbols into the new repos. I will take care of the renaming.

@SchrodingersGat
Copy link
Contributor

And those into Inductors_SMD.pretty and Inductors_SMT.pretty:
Inductors_NEOSID.pretty
Inductors.pretty

You mean Inductors_SMT and Inductors_THT, yes?

@CarlPoirier
Copy link
Collaborator

woops, indeed! I will edit the summary.

@CarlPoirier
Copy link
Collaborator

I completed the simple renames with pull #743.

What is left to do, which all require leaving the old repositories online:

Sockets_MOLEX_KK-System.pretty -> Connectors_Molex.pretty (KiCad/Sockets_MOLEX_KK-System.pretty#1)
part of Terminal_Blocks.pretty -> Connectors_WAGO.pretty (KiCad/TerminalBlock.pretty#6)
part of Terminal_Blocks.pretty -> Connectors_Phoenix.pretty (KiCad/TerminalBlock.pretty#6)

Also all of those into Chokes_SMT.pretty and Chokes_THT.pretty:
Choke_Common-Mode_Wurth.pretty
Choke_Toroid_ThroughHole.pretty
Choke_SMD.pretty (rename to Chokes_SMT.pretty first and add content into it)
Choke_Radial_ThroughHole.pretty
Choke_Axial_ThroughHole.pretty
Air_Coils_SML_NEOSID.pretty

And those into Inductors_SMT.pretty and Inductors_THT.pretty:
Inductors_NEOSID.pretty
Inductors.pretty

@SchrodingersGat
Copy link
Contributor

Sweeping changes have now been made addressing most (all?) of these issues. I am going to mark this one as closed

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

9 participants