kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 06/13/2010 07:30 PM, Wayne Stambaugh wrote:
> On 6/13/2010 4:24 PM, Dick Hollenbeck wrote:
>   
>> On 06/10/2010 04:35 AM, Brian Sidebotham wrote:
>>     
>>>> Thanks for handling this.  I probably wouldn't be able to get to it for
>>>> at least another two weeks.
>>>>
>>>> Wayne
>>>>     
>>>>         
>>> Echo that, thanks for dealing with this patch Dick. If the GUI change
>>> adds too much work, feel free to push this back to me to change, as
>>> the configuration loading and saving will have to change too (as they
>>> use for( size_t i=0; i<DEFAULT_NUMBER_OF_FIELDS; i++) loops).
>>>
>>> I have some free time at the weekend where I could sort it out if needed.
>>>
>>> Also just to add, I've been getting on with bazaar version control
>>> really well, it proved very handy with this patch as I was easily able
>>> to create a quick branch and then occasionally merge with the testing
>>> branch head to keep it relevant.
>>>
>>> Best Regards,
>>>
>>> Brian.
>>>   
>>>       
>>
>> Brian and Wayne,
>>
>> I am very deep into it now.  Will work full time until it is done.  I
>> recognize that the concepts are important, and the intent of the patch
>> is important and useful.
>>
>> I am heading down this road, clarifying and extending some of the
>> original concepts as I go:
>>
>>
>> 1) Fieldnames are to be considered either Default or Wanted.  We don't
>> have that distinction even with the [original] patch.  I define a Wanted
>> fieldname as one that you want for every symbol, that is not a default
>> fieldname.  A default fieldname is one that Kicad supplies after a
>> pristine install of Kicad (you have not specified any Wanted
>> fieldnames).  A Wanted fieldname must always be shown when editing
>> symbol properties, regardless of whether you received symbols from
>> another Kicad user that had all the optional fieldnames filled with some
>> of his own Wanted fieldnames.  Your Wanted fieldnames do not trump his,
>> they simply *must be* added to the end.  (Your "wants" should be
>> granted.  But please limit the context of the previous sentence.)   I
>> don't believe the [original] patch can handle this.
>>     
> Dick,
>
> I think the original intent of this patch (please correct me if I'm
> wrong Brian) was to define a set of user preferred field names to apply
> to the free component fields when creating a new project.  This way you
> always have the same set of user defined field names without having to
> manually edit every component to add these field names.  Your idea of
> adding these fields to the end of any other user defined fields in an
> existing project makes more sense as it works in both use cases.
>
>   
>>
>> 2) Wanted Fieldnames are to be recorded in a way so that they can be
>> referenced when editing symbols, or instantiating symbols, across all
>> projects as provided for by patch (not project or schematic specific,
>> but rather user specific).  However they should also bring with them the
>> *initial visibility* choice.  Often Wanted fieldnames like "Vendor",
>> "Manufacturer", "Cost" or "Installed" (e.g. value=DNS) are not to be
>> visible.  Yes you can override the default on any instantation of a
>> symbol.  But we can save users another mouse click times the number of
>> invisible fields, times the number of instantiated symbols by holding
>> this attribute with the config file saved Wanted Fieldnames.
>>
>>
>> In summary:
>>
>>
>> 1)  Default != Wanted.
>>     
> The term default is a bit confusing.  Typically, library components only
> define the reference and value field.  The only other field names that
> are fixed are the footprint and documentation fields.  The rest of the
> fields can be named anything.  Maybe user defined field names would be a
> better name for this patch.
>
> Wayne
>   


We can call the patch Ralph. 

My definition of "default fieldname" was given in my earlier email. 
Before we can have any more discussion, we would have to agree on
terms.  Or we can chose not to have any more discussion.

Per my earlier email, a "default fieldname" is 1) a name, and is 2) a
name that is not editable.   It is the default should no edits have been
made to the corresponding template fieldname.  Here are the default
fieldnames, and they are not editable (except by translators): 
Reference, Value, Footprint, Datasheet, Field4, Field5, Field6, Field7,
Field8.....   This is my definition.

My earlier definition of a "wanted fieldname" was one that is saved in a
global template, and that will replace a default fieldname.  Wanted
fieldnames can go into the slots normally occupied by Field4, Field5,
Feild6, etc.   A better name which I will now introduce is "template
fieldname".   I do not like "user defined fieldname" for this because
that term does not convey context; remember that templated fieldnames
are changeable on a per symbol basis within the two symbol property
dialogs (library and instantiated/schematic), and one could argue that
that last minute edit of the template fieldname is the true user defined
fieldname.  Feel free to add that as a 3rd definition.

Again, any further conversation, if necessary, should try and conform to
a common usage of terms.  Otherwise I'll just ignore it as too
confusing, honest, trust me.

I was really only trying to give warning that my edits would be more
significant than what I originally described, and that I had detected
some weaknesses in the original concepts of the patch's design.   And
that a templated fieldname, if provided, must always be shown,
regardless of the symbol's history.  If you buy one of Karl's symbols,
then you can expect it to have "manu1" in it.  If your personal
application wide template does not have "manu1", but rather has
"Manufacturer", then the symbol property editors (library and
instantiated/schematic) will show both "manu1" and "Manufacturer". 
Non-blank fieldnames should not magically disappear.  There is nothing
contemplated which magically strips/deletes existing user defined
fieldnames from symbols in my current work.  You can remove user defined
fieldnames in the property editors, but there is nothing about the
notion of a template fieldname that says, "remove some other non-default
fieldname".

That's what I plan on coding in Ralph.

Dick