kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 6/14/2010 12:14 AM, Dick Hollenbeck wrote:
> 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. 

Maybe we can start using clever release names like Debian and Ubuntu ;)

> 
> 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.

Thanks for the clarification.  I just want make sure I understand the
changes.

Wayne

> 
> 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
> 
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>