Skip to content
This repository has been archived by the owner. It is now read-only.

Library Design Recommendations #13

Closed
dbrgn opened this issue Apr 4, 2018 · 14 comments

Comments

@dbrgn
Copy link
Member

commented Apr 4, 2018

We should try to come up with consistent, practical and beautiful-looking recommendations for designing libraries. This should include all things like package design, signal naming and category naming.


First question: When designing footprints, e.g. for an SOT-23-5:

sot235

...should we (1) include the outline of the plastic case in the footprint?

According to @ubruhin, "the solder mask is automatically subtracted from silkscreen to avoid silkscreen on copper", so this would work.

overlapping

Or should we (2) make the rectangle smaller to avoid the pads?

smaller

Or should we (3) work with lines?

lines

I tend to favor (1) because it looks best in my eyes, as long as silkscreen - copper is not a problem.


On a sidenote, I'm not sure if a single RFC issue is a good place to discuss these questions. Maybe we should open a separate repo / issue tracker where every question can be discussed in a separate issue, similar to https://github.com/rust-lang-nursery/fmt-rfcs/issues?

@ubruhin

This comment has been minimized.

Copy link
Member

commented Apr 4, 2018

Yes, I would love to see design guidelines for library entities. KiCad also has that and I think it's very helpful to get high quality libraries: http://kicad-pcb.org/libraries/klc/

The first question is: Where to place these guidelines?

Maybe our users manual at https://docs.librepcb.org would be the right place. Then everything important for users is at the same place. And also it's probably easier to create cross-links, for example the "how to create a package" section could contain a link to the package design guidelines.

Then the existing issue tracker of the librepcb-doc repo could be used for design guideline questions.

For footprint guidelines it's probably best to follow the IPC-7351 rules whenever possible.

@hephaisto

This comment has been minimized.

Copy link

commented Apr 4, 2018

I would tend to make a full rectangular outline of the size of the actual plastic part.
And using the user manual for that is a good idea.

@dbrgn

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2018

Ok, let's move the design questions to the docs repo :)

https://github.com/LibrePCB/librepcb-doc/issues

@dbrgn dbrgn closed this Apr 4, 2018

@dbrgn dbrgn reopened this Apr 4, 2018

@dbrgn

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2018

My suggestion on how to deal with the issues is to label them with tags like these:

tags

And to prefix every issue title with "Conventions:" to differentiate from other issues.

@dbrgn

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2018

@ubruhin do you want the recommendations in the same docs gitbook, or in a separate one? The TOC could look a bit intimidating if we put everything into a single page.

@hephaisto

This comment has been minimized.

Copy link

commented Apr 4, 2018

Maybe one label for each object type (sym, cmp, pkg, dev, pkgcat, cmpcat)?
Naming could be orthogonal.
I don't think that the labelling is that important atm.

@ubruhin

This comment has been minimized.

Copy link
Member

commented Apr 4, 2018

Maybe one label for each object type (sym, cmp, pkg, dev, pkgcat, cmpcat)?

Yeah, I like that system, but I wouldn't use abbreviations. So an issue could for example have the two labels "Convention" and "Symbol".

do you want the recommendations in the same docs gitbook, or in a separate one? The TOC could look a bit intimidating if we put everything into a single page.

I would prefer to have only one gitbook. I guess we can keep the TOC clean as it's a separate file (SUMMARY.adoc).

@dbrgn

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2018

Maybe one label for each object type (sym, cmp, pkg, dev, pkgcat, cmpcat)?

sym and dev can be combined into "naming" and/or "taxonomy". I'm not sure we need a label for every one of those.

I guess we can keep the TOC clean as it's a separate file

Ah, true, we could remove some third-level entries from the TOC.

@hephaisto

This comment has been minimized.

Copy link

commented Apr 4, 2018

sym and dev can be combined into "naming" and/or "taxonomy". I'm not sure we need a label for every one of those.

Not really. There are lots of things that could be discussed for symbols (e.g. default rectangle sizes for pin count, ...) that are not related to naming conventions in any way. Naming is orthogonal to object type.

@dbrgn

This comment has been minimized.

Copy link
Member Author

commented Apr 4, 2018

Sorry, I meant pkgcat and cmpcat 😄

@lukabosnjakovic

This comment has been minimized.

Copy link

commented Jun 8, 2018

Hello I'm new so sorry if I write on wrong issue (suggestion). This issue is Library related so that is why I write here. I'm not sure should my suggestion be a bug or suggestion, but if I find out correctly it would be a new feature. I'm adding element in the Library and that element is a 40 pin FPC connector. I'm doing it with tutorial that is on Get Started docs and I get up to add component part and my "problem" is in component signals part. It looks like this:
deepinscreenshot_select-area_20180608125454
As you see the list is really big (40 pins) and name sort is a mess. I suspect that sort is done but it sorts UUID not human readable name and than you get this :D
My proposal is that you make two columns of this name column (that would be UUID and name) and that you can sort by any of those columns. As I see header column (where says "name") is clickable but it do not do sort like we use to on other programs. I know that this is silly and that it is useful only in some cases, but now it would help me so I can verify that all 40 pins are included. Same thing is on next window (i think is called pin-signal-map) and on window when you open already made component.

Something generally related, lets say that I would like to solve this problem, and that I can, do I solve problem and make pull request or is somewhere place that we all talk about that and then I make fixup or new feature (I understood that this is the that place). I ask because I think maybe we will have more things like that and maybe is silly to open issue every time I (or someone else) think something would be better to be green not blue (hypothetically speaking) :)

Sorry on big post

@ubruhin

This comment has been minimized.

Copy link
Member

commented Jun 8, 2018

@lukabosnjakovic You're absolutely right. I created an issue for that here: LibrePCB/LibrePCB#275

Would be great to see a pull request from you to fix this issue :) I think it would be enough to just always sort by name, no need to make the header columns clickable to sort...

@ubruhin

This comment has been minimized.

Copy link
Member

commented Oct 9, 2018

EDIT: Oops, wrong issue 😭

@ubruhin

This comment has been minimized.

Copy link
Member

commented Dec 14, 2018

@ubruhin ubruhin closed this Dec 14, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
4 participants
You can’t perform that action at this time.