kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Brian Sidebotham wrote:
> 2009/11/5 Wayne Stambaugh <stambaughw@...>:
>> Brian Sidebotham wrote:
>>> 2009/11/5 Dick Hollenbeck <dick@...>:
>>>> Mateusz wrote:
>>>>>> These discussions usually lead nowhere until you have a qualified
>>>>>> developer in hand with about a man-month to actually do the coding.
>> <<< snipped >>>
>>
>>>> So what is wrong *from a user perspective* ?
>>> I only have a few of things that I think are weak points at the moment:
>>>
>>> (1) The value field is in fact the schematic symbol name. For a
>>> resistor or capacitor this makes no sense to me. The value of a
>>> component is something different to the schematic symbol name in a
>>> library. If others concurred then maybe this is a very easy fix.
>> Brian,
>>
>> Currently the value field and the component name are effectively linked
>> even though in the component library file format they could be defined
>> individually. However, in the schematic file format the value field has
>> no relation to the library component name or value field. The schematic
>> L parameter is used to look up the appropriate library component.
>> Changing the component name in a library may break this link so any
>> changes will have to be considered carefully. Generally it would be a
>> bad idea to create custom fields in default component libraries supplied
>> by Kicad because everyone would define them differently which would
>> create a huge mess.
> 
> Hi Wayne,
> 
> Okay, that might be my misunderstanding of the value field then. If I
> understand right, in the library editor Value is used for the
> component name, but in eeschema Value could be changed to be the
> actual value of the component? This makes a little more sense compared
> to how I thought it worked.
> 
> For a new user I think this is still very confusing. I might take a
> look at this to see if there is anything that can be done. In eeschema
> even having a label showing the component library name would be a big
> hint that the value field can be edited and no longer relates to the
> component library name.

I agree. This may be one of those cases where we've given the user too
much information. Maybe we should hide either the name or the value
field in the component library editor to avoid confusion.

> Although I've never seen this question raised on the user list!
> 
>>> (2) The Field1...Fieldn fields are very useful, but also limiting
>>> because it is easy to forget what each field should be used for. It
>>> would be very useful to be able to set up a static set of field names
>>> so that I do not have to type in the field name every time I make a
>>> new component.
>> The user definable fields do not have to be named Field1 ... FieldN.
>> You can give them readable names like "Vendor Part Number" or
>> "Manufacturer" that way you don't have to remember what they represent.
>> If you are suggesting saving a user defined set of default field names
>> to be created each time you create a new project than that would have to
>> be added, which by the way sounds like a good idea.
> 
> Yes, sorry I didn't express myself very well. I do normally rename the
> fields, but it's hard to rename them all consistently and in the same
> order all the time! It would be great to be able to set default names
> for the fields as you correctly surmised.

If this is something that would be useful to users, it needs to be
documented somewhere (Kicad wiki?) so it doesn't become part of the
wishlist graveyard that is this mailing list. I am willing to take a
look at it after I complete the comment translation assuming we can
define what it is we are trying to accomplish. Having a concrete
specification makes coding much easier. Otherwise you are always trying
to hit a moving target. Of course after I complete the comment
translation, the flood of new developers will knock this out in no time.;)

>>> (3) The pin editing options are/were confusing. I see Wayne has just
>>> committed a patch to tidy up the pin dialog so perhaps this is now
>>> easier to understand. The "Edit pins per part" toggle button is the
>>> confusing bit for me. I expect when I select a pin's properties to be
>>> able to set all of its properties, including whether it is shared
>>> among all component parts or exclusive to the visible part. This has
>>> caused a lot of confusion for me before.
>> I have always been confused by the edit pin by pin setting. Even after
>> looking at the code, I'm still not sure how useful it is or even if it
>> is really needed. Does any one use it? If you have any feedback to
>> improve the pin properties dialog, please let me know. I did my best to
>> follow the GNOME UI standards to create a sane dialog box but sometimes
>> it's hard to see the forest through the trees.
>>
>> Wayne
> 
> I use the edit pin by pin setting, I wish it was the default setting
> as it makes more sense to me. Editing pins of parts you cannot visibly
> see seems wrong. Even for a logic gate I would prefer to create the
> common graphics, and then place the pins as needed on each visible
> part.
> 
> I'm never quite sure what's going on otherwise and I always end up
> with pins plastered all over my power part as a result. I rarely make
> logic gate symbols, but I regularly make symbols that have separate
> power symbols and main component symbols. This is where you need to
> remember to click "edit pin by pin"
> 
> Of course, this is just my personal use of the library editor.

I'm a bit surprised by that. Disabling edit pin by pin will clean up
unnecessary pins if you decide change a pin to or from being common to a
part and/or body style. In your case you have to remember to manually
check each part and/or body style for redundant pins. Seems like a lot
of extra work to me. If you comfortable with it, by all means continue
to use it. This may be a case where we haven't given the user enough
information as to why they would want to enable or disable edit pin by pin.

Wayne

> 
> Best Regards,
> 
> Brian.