On 07/29/2014 02:02 PM, Wayne Stambaugh wrote: > 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
I pushed an early branch of this work to milestoneB. See the commit log for some of the details. The shared_ptr turned out to be a can of worms. No, several cans of worms, all stacked like a 2 miles of dominos. So I used a single one per LIB_PART according to this link here, and saved us all a lot of gray hairs. This is a very elegant solution which cherry picks not one IOTA more than what we needed: http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/sp_techniques.html#weak_without_shared I pushed this to branch milestoneB and would appreciate some testing help. There are some TODO items in my section of TODO.txt for this block of work. Most notable is moving the Color loading into the eeschema KIFACE::OnKifaceStart(). Also, the libraries are loaded more often than they should be, I think SCH_EDIT_FRAME needs to quit deliberately loading them and simply use the data on demand technique. You can see schematic editor loading libraries even if you load the lib editor first. This is trivial to fix. I will fix those TODO items along with any bug reports and get 'em done soon. I also saw a segfault somewhere as I was leaving the room. Need to track perhaps a couple of these down. All in all, kicad is more modular, and there's lot to like here I think. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
