kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>