Hello Dick I see a bug in your commit 5072 (also present in latest commit 5079). In that commit; when opening a schematic, then all connections are showed as not connected (with the square green box around the end nodes). When drawing a new wire they all look connected again. See the attached image for how it look.
Not knowing the internals of this, it seems that a calculation of this is not made when opening the sheet. Regards Nick Østergaard 2014-08-04 18:05 GMT+02:00 Dick Hollenbeck <[email protected]>: > 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 : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
