kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

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 <dick@xxxxxxxxxxx>:
> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp

Attachment: unconnected-eeschema.png
Description: PNG image