← Back to team overview

kicad-developers team mailing list archive

Re: Inserting new pins based on pin orientation in eeschema

 

Le 22/04/2015 14:02, Ed Johns a écrit :
> JP and Simon, thanks for your feedback.  It was late when I sent the email
> and I didn't trust myself to refactor. I just updated the calculation. :)
> 
> JP,
> 
> Good point about making sure the update is consistent with the library
> standards.  If the user is using the default grid and default text heights,
> the spacing will be in accordance with the library maintainer's standards.
> Having been burned in the past with different tools' component libraries, I
> often roll my own.  It's less efficient, but that's my workflow.  I'm sure
> this will change moving forward, but there are probably other users with
> the same attitude.  If the consensus is force 100 mil spacing for all pins,
> that's fine and it simplifies the code, but as a user, I prefer versatility
> even when not needed.  I'm not married to either solution.  I just want the
> feature to work without having to do block copies to handle orientation.


I just fixed (rev 5619) the issues with repeat parameters in Eeschema.
The editors have now separate parameters.

I also included you idea about repeat spacing for pins depending on the
pin orientation.
(Thanks for this idea)

About pin positions: for technical reasons they have to be on the 50
mils grid (to be easily connectible in schematic).
(The Libedit checker lists pins which are not on this grid)

The consensus is a pin spacing of 100 mils.

In Libedit, the Libedit setup dialog now allows a repeat pin spacing of
100 or 50 mils, which should be enough for a repeat pin command.

> 
> Simon,
> 
> Since the design freeze is in effect, I was hoping to sneak this change in
> under the wire, making sure it was decoupled from other changes and
> minimizing impact.  After the freeze, I was thinking of addressing the
> direction.  Maybe using SHIFT-INSERT to reverse the direction.  That SHIFT
> usage would be consistent with most development tools.  As far as the
> message box idea, I agree in principle.  However, it would need some form
> of "Don't show me again" to be implemented.  This would need to persist at
> least through the session, which could be implemented as a static.  Best
> case would be in some permanent storage.  Do you know where I would look
> for persistent settings?
> 
> Thanks.
> 
> -Ed



-- 
Jean-Pierre CHARRAS


References