Library organization is fine. Unless something has changed, what's not fine is the precision when changing back and forth between imperial and metric, the craziness with how pin numbers are handled, and not having relative paths. DipTrace's library/component/footprint system is so simple as to make library management irrelevant IF they could make it so that libraries could have relative paths. Maybe this is now fixed and I'm just out of date.
Configurable precision is in the nearest plans - there are number of complains about it. Relative paths - I will think how to handle this, probably add some constants like "project_dir", it's not hard, but we should think how it should be before implementation (your thoughts are welcome). What is wrong with pin numbers?
That's good to hear about the precision. One of my main frustrations is switching back and forth between metric and inches, and suddenly nothing can be lined up anymore.
re: library paths
Here's my situation. I have custom libraries, and I have all of my projects under source control (including all of the libraries, of course). When I switch to another source control directory, perhaps to where I have my releases archived, everything breaks because it goes looking for everything on an absolute path.
All I really want is that ANYWHERE I specify a library (components, linked schematic, whatever...anything having to do with my project) store it as a relative path to wherever my project file is. You don't even need a checkbox or anything like that. Common convention is to give you drive letters for an absolute path, and anything else would be considered a relative path.
re: pin numbers
It's been a while but I have sent some notes about this in the past. Let me try and remember precisely...
Let's say you have a JFET. Depending on the package, this JFET has it's drain, source, etc on different pins. It makes sense to have the pin numbers of the JFET pattern match the pin numbers for the package/datasheet, right?
So I drop this JFET onto my schematic in 50 places, and then I realize I want to use a different JFET. Since DipTrace links the component pin to the package pin via the component pin number, when you replace the component with another component that happens to have a different package, DipTrace will reconnect all of the wires to the original component pin number. Well, Pin 1 used to be drain, but on this package it's Source.
Now I have to rewire my entire schematic by hand. You can imagine how annoying and error prone this is.
Two potential solutions are:
- allow multiple patterns to be attached to a single component
- attach the wires on the schematic based on pin NAME instead number...the default pin name is just the pin number, and I'll change it to something meaningful later if I want to.
IMHO, I don't even think a component needs a pin number at all. It could potentially only have a pin name (which could simply default to a number). Schematic should be attached by pin name. Pin number should be inherited from whichever pattern you've selected.
This way everything makes logical sense. Schematic connects by name and will never change when a component is replaced. Attaching a pattern to a component links the pattern pin number to the component pin name. If you display the pin NUMBER on the schematic, you get the pin number from the attached pattern.
Now I have all the information I need, and the logical connections on the schematic are completely decoupled from the physical pattern. This also makes it pretty easy to have multiple patterns attached to the same component, or lays the groundwork for that anyhow. The ideal situation is to have both solutions, and I think they go hand in hand because they're both based on the same idea of decoupling the schematic from the pattern.
I don't know if I explained it well but I think it would be a very worthwhile change to consider.