On 1/3/2011 6:35 PM, Dick Hollenbeck wrote: > On 01/03/2011 03:59 PM, Wayne Stambaugh wrote: >> On 1/3/2011 3:36 PM, Dick Hollenbeck wrote: >>> On 01/03/2011 01:58 PM, Dick Hollenbeck wrote: >>>> Wayne, >>>> >>>> I just made a commit that fixes some minor issues to a commit I made last >>>> night, and I can now see the inheritance mechanism working really pretty >>>> well. >>>> >> Dick, >> >> I've attached the changes I made to the library part file specification last >> night. I updated all of the coordinates for dimensionless units. All I did >> was divide all of the coordinates by 50 (mils). > > Beautiful. > >> I added a short blurb about >> logical coordinates. > > "pin cell" is another name that came to mind, again like drawing pins on > graph paper. Logical coordinates are fine too, but requires more > intellectual energy to understand IMO. > > Having more than one way to describe the concept is good, whatever we can > can stack up to convey the concept, and it may require a couple of different > approaches for folks to understand. Logical coordinates are a fine > approach. I just wouldn't start there with my Mom. I would start with > graph paper and the notion of a pin cell, which is the same as what she sees > on the graph paper.
I think I can use the graph paper analogy to describe logical units. In reality they are the same thing. If I have some free time and feel motivated enough, I'll create a SVG file that illustrates the concept. This may be one of those cases where the picture is more meaningful than the description. > > > >> I also renamed route_pin_swap and route_alt_swap to >> hint_pin_swap and hint_alt_swap. I think route is too tool specific. A >> hinting system that is tool agnostic makes more sense to me. >> >>>> Today is a company holiday I was not aware of, so that gives me another day >>>> to work on this stuff in an active mode. My normal mode would be more >>>> intermittent, or weekend centric, than what I can spend on it today. >> Always a nice surprise. >> >>>> I will make another commit very late this evening, and then take a less >>>> active role for the remainder of the week, which could give you some time >>>> on it. >> I'll start messing around with it tonight as I have some to kill tonight. >> >>>> ================= >>>> >>>> Units: >>>> >>>> My thinking is that we do not have units, but if you wanted to name them >>>> they might be: >>>> >>>> "pin intervals", "pin spaces", or "pin deltas", which means of course, the >>>> standard minimum distance between two pins in the new EESCEMA. >>>> >>>> A value of 1 pin delta is what you'd often see in the Sweet strings, >>>> *between* pins, in either X or Y axes. >> I was thinking more in terms of logical units. All items that are >> connectible >> (pins, wires, labels, etc.) must have integer units to guarantee >> connectivity. > > Well "must have" may be too strong. But we agree on the concept. The only > reason to stray from this is to handle the case where an old part was just > so poorly designed, and it needs to be converted, just to get it into a new > editor environment. The coordinates may not be on a pin cell boundary. We > can support fractional pin cells, but don't want to as a rule. If we provide support for automatic snapping to connectible objects in EESchema, then non-integer values would not be an issue. If you don't provide it, you are opening yourself up to a slew of bug reports and user confusion when their connectible objects are off by one pixel and they get a bunch of ERC errors. Maybe the conversion tool should warn the user and give them the option to move pins to the nearest integer value. > >> All non-connectible items (lines, text, etc.) can have non-integer units as >> well. > > Any can have any. But on the assumption that everyone wants to conform, and > create a maximally re-useable part, then everything should be on a pin cell > boundary, including text. We can flash a red box on screen if someone > doesn't want to wear the school uniform. > > >> This way it doesn't matter internally what EESchema uses as it's >> coordinate scalar other than making sure you don't overflow or underflow the >> integer. > > > Yes, the accumulation of Intellectual Property, is in the growing body of > Sweet specs. > > This is our goal, and I think it has the potential to transcend Kicad. If > we do this right, then this thing will be adopted outside Kicad, no > question. We will take a bow when some part vendor provides a Kicad library > in Sweet form, and puts it up using HTTP_LIB_SOURCE. I feel a another world domination proclamation coming. Wayne > > > Dick > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp