kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

> I think I have a decent understanding of how the API interfaces with
> EESchema.  I can see how the classes fit together to create the part
> library API. I guess I'm thinking of what happens after the part library
> API is loaded by EESchema.  How do the parts get drawn?  Where are the
> arcs, circles, lines, etc. objects that are part of a SCH_PART reside?
> We already have these objects that are fairly robust if less than
> optimally designed (I'm working on that).  Maybe I'm thinking too far
> ahead or am missing something.


They go into the PART of course.

I was going to try out the GAL, and we had agreement on the dimenionless
coordinate system, where the pin to pin distance is one unit.

So I will try and re-use what we have for those drawables where it makes
sense, and I may only get to a few of them before Monday.

TEXT is a big point of departure, since we have that separate EFFECTs concept.

I just completed a IO_ERROR() and PARSE_ERROR() upgrade, and now can capture
the call site info of :

__FILE_  __func__ and __LINE__

through what was a fairly brutal trial and error effort.

To get these you have to use the macros THROW_IO_ERROR() and
THROW_PARSE_ERROR().

When catching it seems we can catch either with

catch( IO_ERROR& ioe )

which works for both only if caught *by reference* only.

If your compiler does not support __func__, richio.h may have to be doctored
until we get some ifdefs in there.





>> Although you COULD augment existing EESCHEMA to write Sweet files, it
>> becomes nothing more than a conversion program at that point (but perhaps a
>> decent conversion program).
> I think that is something most users will want.  Using a script or
> external program to convert from the current file format is something
> most users will frown upon.
>
>>
>> Old EESCHEMA will not be able to use the new API because:
>>
>> The API owns all the PARTs, it only lets the schematic reference them within
>> the LIB cache.  And then there is the parts list.  So EESCHEMA will need to
>> be rewritten in effect, at least 60% of it.
> I order for this to happen we will need to start defining the new
> schematic file format.  I don't think mixing the existing file format
> with sweet would get rather ugly.  I can start putting together a
> preliminary schematic file specification over the next month or so.

Very true.  There is a lot of work that can be done from ground up, for
quite a while yet.

The textual part editor and the parts list UI panel could stand alone on top
of the code we now have.

Before the parts list UI is done, we should not place any large bets.  That
is the riskiest portion of the design.  The spreadsheet view will have to be
able to come into the PARTS_LIST and jam the desired set of
FIELDS/PROPERTIES down the throat of all the PARTS in the PARTS_LIST, so
they all have the same columns.  So this will be one of software
engineering's finest hours if we can pull it off.

It may have to be one with a facade of some kind.

Happy New Year to everyone.


>> This is my perspective.  (And any time we talk about augmenting the existing
>> code, I will begin to wonder why, I will question why.)
>>
>> Basically email is starting to suck for this.  We may need to open up an IRC
>> or use skype if it gets any more involved.
> I have neither a Skype nor an IRC account but it won't take long to
> create one or both.  If (when?) we get to that point, let me know which
> medium you prefer and I will get it set up.
>
> Wayne

Let's keep it in mind, especially if we are active at the same points in time.

Dick