kicad-developers team mailing list archive

[Wayne Stambaugh <wstambaugh@xxxxxxxxx>]

Dick and I have been discussing his ideas on making schematics and therefore
parts dimensionless.  The more I think about it, the more I like it.  Please
look over the discussion below and feel free to comment.  I have also attached
the revised part specification with Brian's part renaming suggestion.

Wayne

-------- Original Message --------
Subject: Re: Patch for kicad gal
Date: Wed, 15 Dec 2010 13:07:23 -0600
From: Dick Hollenbeck <dick@xxxxxxxxxxx>
To: Wayne Stambaugh <wstambaugh@xxxxxxxxx>

On 12/15/2010 12:23 PM, Wayne Stambaugh wrote:
> On 12/15/2010 12:15 PM, Dick Hollenbeck wrote:
>> On 12/15/2010 10:55 AM, Dick Hollenbeck wrote:
>>> On 12/15/2010 10:18 AM, Wayne Stambaugh wrote:
>>>> On 12/14/2010 5:44 PM, Dick Hollenbeck wrote:
>>>>> On 12/14/2010 03:38 PM, Wayne Stambaugh wrote:
>>>>>> On 12/14/2010 1:54 PM, Dick Hollenbeck wrote:

<<< snipped >>>

>>>>>>>
>>>>>>> As I was reading your spec.  I began to wonder if it would be helpful for *human
>>>>>>> writability* if:
>>>>>>>
>>>>>>> The units of the coordinate system were grid oriented.  In other words, if we could
>>>>>>> superimpose an additional cartesian coordinate system that was at a lesser resolution
>>>>>>> onto the normal coordinate system.
>>>>>>>
>>>>>>> In this mode, pins might be 1 unit apart, vertically or horizontally.
>>>>>>>
>>>>>>> Don't know if we can do the same for text or pin names.  But maybe.  Maybe this makes
>>>>>>> writing Sweet with a text editor easier?
>>>>>>>
>>>>>>>
>>>>>>> (gxy X Y)   grid coordinate  (maybe it implies a division of X and Y by 50 or so.)
>>>>>>>
>>>>>>> (xy X Y)    units coordinate
>>>>>> I'm not 100% sure if I follow you.  If the xy coordinates where in terms of
>>>>>> grid (gxy), wouldn't that mean a conversion in order to figure out where a item
>>>>>> is located relative to the grid? 
>>>>> Again, I am not over selling, but I want you to understand my original thinking, at
>>>>> least enough to tell me it's foolish or not worth it:
>>>>>
>>>>> First I start by assuming dimensions in the schematic are not even important unless I
>>>>> go to print.  Dimensions, i.e. *scaling*, could be added at the eleventh hour just
>>>>> before printing.  EESCHEMA only.
>>>>>
>>>>>
>>>>> What is important is that the grid let me connect wires to pins.  So if the pins are
>>>>> on grid points, the wires are on grid points, then what is not on a grid point?  Text
>>>>> can be on a grid point.  What is left is arcs, curves, but very little else.
>>>>>
>>>>> Therefore, in some cases all we need is a ficticious coordinate system that is based
>>>>> entirely on grid points *alone*.
>>>>>
>>>>> If (xy 100 200) were a valid point before, then (gxy 1 2) becomes the *same* exact
>>>>> point expressed in grid coordinates, assuming the grid was 100 x 100 original units.
>>>>>
>>>>> Basically what this does is eliminate some trailing zeros, on the assumption that grid
>>>>> points are the only points of interest, and that the grid is a multiple of 10.  If the
>>>>> grid is 200 x 200:
>>>>>
>>>>> then (xy 200 2000)  becomes (gxy 1 20)
>>>>>
>>>>> And the author of the code in his TEXT EDITOR might find this easier.
>>>>>
>>>>> It requires that you don't ever need to go off grid.   And admittedly this is not the
>>>>> case with curves.  So I don't know if it is easier or harder. 
>>>>>
>>>>> That is one line of thought, two coordinate systems. 
>>>>>
>>>>> An alternative line of thought is to have one coordinate system but have it BE the
>>>>> grid system in all cases, and use fractions to go off grid, like (xy 1.25 4.5).  So
>>>>> pins *by request or by definition* are one X unit or one Y unit apart.   Then only at
>>>>> time of printing do you assign the scaling factor, and which point you can stretch the
>>>>> schematic to any size you want.  Likewise during editing, you can stretch to any size
>>>>> you want.  The schematic is essentially dimension-less.
>>>> This concept has a lot going for it.  I like the idea of a dimension-less
>>>> schematics.  You would never have to worry about pins being off grid and not
>>>> connecting properly to a wire or bus no matter where you placed them in the
>>>> schematic.  My main concern is how easy is this going to be for users to
>>>> understand given that the initial part file editor is going be text based.
>>>> Converting off grid part coordinates is going to be confusing.  It will also
>>>> make specifying things like line width and text height and width relative to
>>>> the grid spacing difficult as well.  A graphical editor may be required to draw
>>>> off grid elements properly.  This will definitely have to be determined before
>>>> we start coding.
>>> Well we can make all the new kids wear uniforms to school, metaphorically.  This means
>>> we challenge the need for text that does not fit within a grid unit.  Maybe all text
>>> is the same size in EESCHEMA, by default any way.
>>>
>>>
>>> Converting existing symbols over we can simply use fractional numbers if they go off
>>> grid.  But
>>>
>>>
>>> (pin ..(xy 1 2) ..)
>>> (pin ..(xy 2 2) ..)
>>>
>>> gets pretty easy, it reminds me of using graph paper as a kid.  In fact a person could
>>> draw his part on graph paper and then simply key it into a text editor.
>>>
>>>
>>>
>>> Line width, two alternatives:
>>>
>>> A) Line width can be imposed globally on a schematic for screen drawing or printing,
>>> each separately controllable globally.  But all lines would be same width.
>>>
>>>
>>> B) Line width takes on the units of "percent of a grid cell", so a width of 100 would
>>> be one cell wide (fat line), 200 would be 2 cells wide (fatter line),  and 1 would be
>>> 1 percent of a grid cell, or a single pixel if greater.  5 would be about right I think.
>>>
>>>
>>>
>>> Where there is a will, there is a way.
>>>
>>> If we can achieve human *writability* this will mean major things to the adoption of
>>> Sweet.  BTW, I had never contemplated not writing a graphical editor also, but now it
>>> is at least a remote possibility, could actually be omittable if we can get this easy
>>> enough. 
>>>
>>> (I had envisioned *both* textual and graphical, with the graphical elements the of
>>> base parts being off limits to graphical editing unless the inheritance was meant to
>>> be a full blown copying.)
>>>
>>> The last thing to remember about this dimensionless concept, is that you would never
>>> have a schematic that would not fit on the page.  It would always fit, it just might
>>> be harder to read, since it would be small.  Or if you are lucky, you get to make it
>>> really big as you go blind and old.
>> Text:
>>
>> The anchor point for text would be on grid too, so you would have enough space below
>> capital letters so that the text could reside above a wire or pin without stepping on it.
>>
>> Sort of like the PCBNEW wire label concept.
>>
>> That whitespace offset beneath the font, would be hard coded into our stuff, so the
>> user never has to think too much about it.  Text and wires co-mingle nicely.  Text is
>> on grid from a Sweet standpoint.
>>
>> That way pin names and explicit separate text would be on the same level.
>>
>> Well I've almost talked myself into this now.  If you are nearly sold, we may want to
>> ask for more opinions, feel free to do that if so.
> I'm sold.  I'll remove the GAL stuff and forward this email conversation to the
> mailing list for comments if there are no objections.
>
> Wayne

No objections.

For line width you can add a 3rd alternative, that being to use the same
dimensionless
units as everything else.  So instead of a line width of 5 for 5% of a grid,
you would
simply say .05

And you can get a lot of mileage by publishing defaults, or by using global
settings,
so only line specific overrides have to be expressed in Sweet.  Therefore line
width
may not even be needed most of the time.  When parsing, you could set the
binary line
width value to -1, and let either the default pertain, or a global.

Same for text size, could be in grid/snap units too.    A height of 1 means
just less
than a full grid cell.  Height of .5 means half high.  Or you could go with the
cell
*percent* on both, probably means less decimal points, but who cares either way.


Dick

Attachment: eeschema_part_sexpr_format_EN.odt
Description: application/vnd.oasis.opendocument.text