kicad-developers team mailing list archive
Mailing list archive
Re: Sweet parser
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:
>>>> 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.
>> 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).
>> 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
>> 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.
>>>> 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
> 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
> 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.
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp