On 7/27/2014 1:33 PM, Dick Hollenbeck wrote:
Gentlemen:
In the course of trying to load the schematic editor directly under kicad.exe, by-passing
eeschema top frame itself, I was exposed to a range of issues in the design of eeschema.
Firstly, I discovered the most excellent work by Wayne Stambaugh regarding the schematic
library containers.
Thanks Dick. I wasn't really expecting any credit. I was just one of
those things that needed fixed so I fixed it. I knew that that only way
to move Eeschema forward was to fix the underlying library containers.
I wish I had the time to finish the SCHEMATIC object and come up with a
better way to handle sheet hierarchies. With those two pieces of the
puzzle in place, we could start moving towards the new file format and
other enhancement that we have discussed over the years.
There are a long chain of dependencies here. LIB_EDIT_FRAME, to come up first, needs the
libraries. That is obvious in words. But SCH_EDIT_FRAME typically loads the libraries
before popping up LIB_EDIT_FRAME. You have a similar discussion about LIB_VIEW_FRAME.
(I believe I solved all these similar problems for PCBNEW.) So now I went to solve them
for EESCHEMA and produced an 11,000 line patch in 2.5 days. Remember that about only
1/7th of a patch line count are actual changed lines.
The eeschema libraries were global, even if hidden behind a static class function, they
were global. This would not dovetail into the notion of multiple open projects, each
having its own set of libraries. So in the course of moving libraries into a project
specific container, lots of changes were needed. First among those was to park the
libraries container in the PROJECT. It was a necessary but insufficient solution for
multiple open projects. One remaining issue is the fact that with multiple open projects
you'd still have the same library open twice. Its hard to have the same problem in
PCBNEW, (would have to duplicate project specific libraries) and even if you did, most of
the plugins react to a change on disk and will re-cache if one of the copies is edited.
We now have the libraries container in the PROJECT at least, and it is loaded on demand,
by any _eeschema.kiface KIWAY_PLAYER that needs it.
For 5 years or more no one questioned the terminology I introduced in the SWEET
distributed library design regarding the definition of PART and a COMPONENT. The time to
object was 5 years ago. So I went with those original terms per that prior design.
LIB_COMPONENT is now LIB_PART. SCH_COMPONENT remains.
Works for me. I've always thought that LIB_COMPONENT and SCH_COMPONENT
naming was confusing.
SCH_COMPONENT uses a link to a LIB_PART. That link was previously done by a library
search on every Draw() call. This was easy since the library container was global, and
the SCH_COMPONENT had access to the global container. Not so now.
I seem to remember some other global variables used by the Draw()
functions. The color table and possibly some visibility settings come
to mind. I don't know if these have any context per project but it may
be one of those things you want to look out for just in case.
This also introduced an avoidable performance hit, which is avoided if a link to the
LIB_PART is retained across SCH_COMPONENT redraws.
You can pretty much now tell where this took me. Squarely into boost::shared_ptr and it
companion class boost::weak_ptr.
I will get it working in another half day and push it to its own branch, and would like
folks to use EESCHEMA for a couple of days in that branch.
My son and I are doing a very complex board
together.
And you can load the part editor and footprint editors directly from kicad.exe, for a
single project now.
Awesome work Dick! I'll try to do some testing as soon as I see the
branch on launchpad.
Wayne
