short title:
Symbol Editor: I don't think making a new derived symbol works the way it
should.
Summary of issues:
1. If you make a derived symbol from an existing symbol the VALUE field
will generally be the one from the symbol you are deriving from (parent
symbol). It should be the same as the name of the new symbol.
2. A new derived symbol has blank FOOTPRINT and DATASHEET fields. FOOTPRINT
should be copied over. Maybe DATASHEET too.
3. If you double-click a symbol to look at it to confirm it is the right
one then select "new symbol" you get an error saying "No symbol library
selected." It should instead offer to make a symbol in the library of the
symbol you are viewing.
Long-winded reasoning and arguments:
1. While there are other conventions for drawing symbols the typical way of
doing it should be probably be considered to be the way that the KiCAD
library conventions describes. And convention S6.2 item 2 says: 'Value
field contains the name of the symbol and is visible'. Contains here is not
defined but seems from the other rules to mean "has the value of" instead
of "has a value which includes the substring of". Hence we should expect
the value field to be the same as the name of the symbol you are creating.
If using the new derived symbol functionality currently the value field
will likely be the same as the name of the parent symbol, not the symbol
you are creating. And in fact I made this error multiple times when
creating new symbols for the KiCAD library. The checker script found the
errors for me.
The existing implementation does this to set the VALUE field in the new
symbol:
case VALUE_FIELD:
if( parent->IsPower() )
field->SetText( name );
break;
So only for power symbols does the derived symbol take the new name. I
suggest that the field should always be set to the new name. Another
alternative is to set the VALUE field to the new name if the VALUE field is
currently set to the name of the parent symbol.
2. The existing implementation includes this argument for these fields:
case FOOTPRINT_FIELD:
case DATASHEET_FIELD:
// - footprint might be the same as parent, but might not
// - datasheet is most likely different
// - probably best to play it safe and copy neither
field->SetText( wxEmptyString );
break;
When considering this it is important to note that the pins values cannot
differ for the derived symbol. The symbol itself is not editable and the
"Pin Table..." button in the editor is greyed out. A message even comes up
indicating the symbol is not editable and suggests opening the parent.
Given this the pins mappings must be identical in the derived symbol. This
does not mean the footprint must be the same. However I indicate that this
means that the footprint is most likely to be the same. In fact a major
reason to copy symbols instead of deriving from them is to change the pin
mappings and footprint. I therefore suggest that the FOOTPRINT field should
be set the same as the parent symbol.
Whether the DATASHEET should be identical is a bit less obvious. I can say
it would have saved me a lot of time when making symbol libraries if it was
identical. The only strong reason I can think to erase it is so that the
creator of the new symbol does not forget. And given that there is no real
good reason to leave this blank (the guidelines suggest a value of "~" for
generic symbols) I don't see a lot of value in a blank field. However I
leave this up to others to argue more about as I don't feel strongly about
this.
3. This issue arises because when you double-click a symbol it becomes
unselected in the browser list. It is selected on the first click and
unselected on the second. It no longer is drawn in the highlight color but
instead now has a box around it. If you double-click and then single click
and then select "new symbol" it works fine. I can see no reason that
double-clicking a symbol should leave you with no symbol (nor library)
selected. I propose that double-clicking should leave the displayed symbol
selected. This will change the behavior of selecting copy after
double-clicking, as currently selecting copy does nothing since nothing is
selected. Also deleting the currently displayed symbol will operate
differently, as it is not possible to delete the currently displayed symbol
without selecting it again.
Another possibility would be to leave this behavior as it currently is. It
is something you can "work around" once you see it. It's just that it feels
unnatural.
I am willing to do the work on this change, I am looking essentially for
some behavioral "rulings" from those who define such things. How do the
project leaders feel this should work?
--
You received this message because you are subscribed to the Google Groups
"KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/kicad.org/d/msgid/devlist/5fadf69d-042e-49e5-9c58-512042e90ff5n%40kicad.org.
