kicad-developers team mailing list archive

[Daniel Silverstone <dsilvers@xxxxxxxxxxxxxxxxx>]

On Mon, Feb 29, 2016 at 13:18:26 -0500, Wayne Stambaugh wrote:
> I stumbled across your blog report this morning before your post to the
> kicad dev mailing list and I'm having a difficult time figuring out what
> your changes provide.  The trickybox only seems to provide a visual
> symbol for dangling connections where as a label does not.  However, the
> label still creates the physical connection between "dangling" wires
> and/or buses be they on the same sheet or a different sheet.  You can
> test this for yourself by opening the video demo schematic and deleting
> one of the labels from the root sheet and running the ERC.  The ERC will
> report unconnected wires and/or buses on other sheets as expected.

Certainly I expect the net connections to continue as they currently work.
 
> In the past we've talked about actually using the netlister to close the
> dangling state box (the little square at the end of an unconnected
> object that has a connection point) when labels join dangling wires
> and/or buses so it's obvious to the user when dangling wires and/or
> buses actually have a connection.  The problem with that approach is the
> amount of time required to regenerate the netlist to determine the label
> connectivity may cause UI delay issues.  To be honest, we haven't tried
> that yet so my concerns may be unfounded.

My concern is to do with net lines which *might* be incorrectly dangling or
*might* be deliberately dangling.  It's that uncertainty which leads to the use
of an explicit intra-sheet link element, just like the point of offering the
no-connect element to allow engineers to state that they meant for that pin of
a symbol to be unused.

> FYI, we have frozen the existing file format because it is going to be
> replaced during the current development cycle.  Your changes require a
> file format change which is not going to happen.  I wish you would have
> inquired about this on the kicad dev mailing list before you wrote your
> code.  We certainly can discuss added your changes to the new file format.

I guessed that might be the case and I'm certainly not upset by the potential
delays.

> In the future, would you please post you ideas to the KiCad dev mailing
> list rather than the Debian blog.  I was rather surprised to see someone
> doing some serious hacking on KiCad outside the project.  It's always a
> good idea to run things by the kicad dev mailing list first before you
> start hacking on kicad just to get and idea what's going on in the
> project.  I consider developers time a precious resource so I hate to
> see someone spend a lot of time hacking on kicad on something that we
> may not be able to use because of other ongoing development.

I did the original work, mostly to see how hard it'd be for me to hack on
eeschema -- I wasn't under any illusion that this would be anything but a
shot-from-the-dark for other KiCad developers, but I hate being the sort of
person who shows up on a list, gets people interested in an idea, and then has
no code to show for it.

As someone used to things like the Linux kernel where code-is-king rules apply
I tend to hack first, send RFC later :-)

That my blog is aggregated to various places such as the Debian Planet is just
a side-effect of the number of communities I find myself in, and was not
intended in any way to be a mechanism to put pressure on yourself or others in
the KiCad community.

> Thank you in your interest in contributing to KiCad.  I will take a look
> at your concept when I get chance and comment on it.

I look forward to any comments you have about the idea -- given your confusion
above about the goals of the intra-sheet link elements, it's clear that despite
my attempts to clarify the position, I still have failed to communicate it
effectively.  I shall think about other ways to do so.

D.

-- 
Daniel Silverstone                         http://www.digital-scurf.org/
PGP mail accepted and encouraged.            Key Id: 3CCE BABE 206C 3B69