kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/27/2011 04:44 PM, Vladimir Uryvaev wrote:
> At Monday 28 of November 2011 01:13:53 from Dick Hollenbeck:
>> Good catch on the %g going to exponent format when fabs( double ) <= .0001 
>> !
>>
>> If using a number in the e notation below 0.0001 bothers you, I will
>> revisit the strategy.
>>
>> I used this format %g format string with good luck in the specctra_export
>> code, but it seems we were working with larger numbers there.
>>
>> I don't share your views on the human readability of data files.  I believe
>> that one of KiCad's main value propositions is human readability of data
>> files.  SWEET takes this to the extreme, and s-expressions are arguably
>> even "self documenting".
> Is it self-worth feature for you? If you insist on your view of schematic, i 
> will not hinder you, do anything you want. There's shouldn't be two kings in 
> one domain.
>
> I wonder if anyone need this. If one really need to read and write sch files 
> format reckoning wouldn't be a problem, for another this does no odds. 
> Futhermore, reading kicad-users mailing list suggest me that this is more 
> likely a bug than feature, as many users try to edit them, get weird result, 
> ask mailing list and get answer that files couldn't be edited manually.
> PCAD have ASCII file format, but just as an alternative to binary, used mainly 
> for version control and interchange, specctra files intended to be 
> writable/editable by the user, and that are substantiate decisions. Does human 
> readability of KiCAD files have its substantiation?
>
> Anyway KiCAD popularity is not a matter of file readability, but lack of 
> competition from Free&OSS. :)
>
>
>> So it is not clear to me that a function written by you for this purpose
>> would serve previously stated goals.
>>
>> If you are insistent on no exponents in the number, I am insistent on the
>> smallest files including trailing zero removal where we can.
> Being self documenting and smallest size are contradict features, don't you 
> think? ;) Self documeting means adding redundant information, and shrinking 
> size meand removing it.
>
>> fprintf( fp, "example coord: %3s %3s\n",
>>     biuFmt( pad.x() ).c_str(), biuFmt( pad.y() ).c_str() );
> Why don't you use iostreams for this?

Vladimir,

Thank you for your patience with me.  You have been conscientious in your efforts to find
the best solution for KiCad, and you have refrained from calling any one names.

So thank you.  It looks now like we are unable to reach agreement on this file format.  So
I think in the interests of the project that I should just go ahead and write the plugin
the way I think it should be written.  It will serve as an example, and then other plugins
can be written that use alternative file formats.  I hope this one which I am about to
write has a short life.  I do want to support s-expressions soon.  This will be our "old
school millimeter" format, which will be newer than our "old school deci-mil" format which
we currently have.

It would be really cool if someone could soon step up and write an importer/exporter
from/to EAGLE's shiny new XML format.  I see no reason why that cannot go into the plugin
design, nor why we cannot do this for geda PCB also, nor why we cannot do this for an
s-expression format with shiny new constructs in it.

This current file format disagreement is minor, I think we traveled through much ground,
and for two individuals at our skill level to be arguing about the number of zeros after a
decimal point is not something that I can afford to do.

Thank you very much, and I will look at your work within the UI and elsewhere for the
nanometer support when it is available.  I hope we can find more agreement there than we
did here.

Dick