kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Sun, May 11, 2014 at 12:52:37PM +0200, jp charras wrote:
> int clockPinDim = m_numTextSize/2;
> 
> and later in code:
> GRMoveTo( x1, y1 + clockPinDim );
> 
> or (better?)
> #define CLOCK_PIN_DIM m_numTextSize/2

sure, no problem. The C++ recommended form should be

const unsigned clockPinDim = m_numTextSize / 2;

...except that maybe int would be a better idea given the ugly rules
about sign mixing (and the resulting wave of compiler warnings).

On the extreme that should be really an inline const member function, or
an utility function taking the pin as an argument. A local function in
the implementation for the pin is IMHO the neater solution (no need for
fattening the interface).

> (Why to use num text size instead of name text size, for instance, when
> the pin name and pin num are both outside the component body).

Well, the special pin types would only be used on box components (in
fact they are only defined to be used in 60617-12 and -13), so the name
would be always be inside. Also the size rule would say that text should
be of the same size, anyway... since we want to keep flexibility, maybe
the dynamic input marker (the 'clock triangle'), could be better indexed
on the pin text size. With proper usage (i.e. name and number of
consistent size) it wouldn't matter.

> I frequently use small numTextSize or nameTextSize values, and do not
> see why the pin shape should change when changing this parameter.

I would like to say 'because EN60617 says so' but I agree that would lose
flexibility. In fact, all the text should be of the same size in that
case, too (and that size would depend on the paper size; good luck doing
libraries with this rule without the LU stuff in place)

This size should really go somewhere in the schematic settings, but
not in user preferences, because then appearance would change on a user
basis when transferring the file. Definitely *not* a good thing. The
definitive solution would be *another* size in the pin record... do we
really want this? I think that choosing the number size for the outer
symbols and the text size for the inner one could be the best compromise
(maybe the nonstandard falling clock should be indexed with text for
uniformity?)

As for the default values (like the 300 mil changed to 100 for pin
length), a field could be added to the user preferences (along with the
default text size and stuff). Since that's a default only, that would
not matter when exchanging drawings.

-- 
Lorenzo Marcantonio
Logos Srl