On 08/31/2011 05:11 PM, Brian Sidebotham wrote:
On 31 August 2011 22:42, Dick Hollenbeck d...@softplc.com wrote:
Your best bet is to take a look at the generic netlist export, which is in
XML.
That format we hope to preserve, while the world around it might morph, for
good
cause.
On 1 September 2011 14:58, Fred Cooke fred.co...@gmail.com wrote:
You can't improve anything without making changes, Dick.
An oxymoron there considering you're trying to argue the below:
And his point re
breaking the API that exists (he's not the only one who has scripts against
your text
libraries from what they are now to
key-value pairs in a new file format. And I can deal with that file
format not handling null strings.
But it's a bit rough on those of us using kicad to pull the rug out from
underneath us by jiggering the existing file format. If you aren't
On 1 September 2011 06:28, Dick Hollenbeck d...@softplc.com wrote:
Proposal:
Are you ok with licensing this work under GPL? If so, can we check these
into a
contrib directory or something, as part of the tree, along with a readme.txt
or
readme.html file?
(Although I think that posting
On 9/1/2011 1:28 AM, Dick Hollenbeck wrote:
Proposal:
Are you ok with licensing this work under GPL? If so, can we check these
into a
contrib directory or something, as part of the tree, along with a readme.txt
or
readme.html file?
(Although I think that posting which talks about
On 09/01/2011 03:33 AM, hauptmech wrote:
libraries from what they are now to
key-value pairs in a new file format. And I can deal with that file
format not handling null strings.
But it's a bit rough on those of us using kicad to pull the rug out from
underneath us by jiggering the existing
You can't improve anything without making changes, Dick. And his point re
breaking the API that exists (he's not the only one who has scripts against
your text files and prefers kicad for text file storage reasons) is valid.
Why the unpleasant attitude? :-/
On Thu, Sep 1, 2011 at 3:51 PM, Dick
On 08/31/2011 08:31 AM, hauptmech wrote:
From the bzr log message is appears that fields not in the template list
will be deleted on exit from the component edit dialog. Or read
differently Fields with a null value and not listed in the template list
will be deleted (which seems to be the
On Wed, 31 Aug 2011, Dick Hollenbeck wrote:
Life is too short for this.
Use the template fieldnames, put all your fields in there, every last one of
them, then if they are blank, they go away. Search for your fields by name.
The number is going away, period.
Agree 100%... it's more than 30
On 8/31/2011 12:16 PM, hauptmech wrote:
On Wed, 2011-08-31 at 09:23 -0500, Dick Hollenbeck wrote:
On 08/31/2011 08:31 AM, hauptmech wrote:
From the bzr log message is appears that fields not in the template list
will be deleted on exit from the component edit dialog. Or read
differently
On 31/08/2011 9:35 p.m., Wayne Stambaugh wrote:
On 8/31/2011 12:16 PM, hauptmech wrote:
On Wed, 2011-08-31 at 09:23 -0500, Dick Hollenbeck wrote:
On 08/31/2011 08:31 AM, hauptmech wrote:
From the bzr log message is appears that fields not in the template list
will be deleted on exit from
Your best bet is to take a look at the generic netlist export, which is in
XML.
That format we hope to preserve, while the world around it might morph, for
good
cause.
http://www.mail-archive.com/kicad-developers@lists.launchpad.net/msg00531.html
Brian, where did we ever put your python
On 31 August 2011 23:11, Brian Sidebotham brian.sidebot...@gmail.com wrote:
On 31 August 2011 22:42, Dick Hollenbeck d...@softplc.com wrote:
Your best bet is to take a look at the generic netlist export, which is in
XML.
That format we hope to preserve, while the world around it might morph,
Proposal:
Are you ok with licensing this work under GPL? If so, can we check these into a
contrib directory or something, as part of the tree, along with a readme.txt or
readme.html file?
(Although I think that posting which talks about the %B etc, is close to what
might be good enough.)
If
14 matches
Mail list logo
