kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

>Not disagreeing with you on this one, but I would have to question why...

Did you skip the why section?


Because we are supposed to have a standard file parser and reader that
is maintainable. What there is a micro-optimization obsessed VB6
parser. There's a keyword enum pre-generation that just adds pointless
back and forth (a class with const strings is more than enough). If we
are reading "s-expressions" then there should be a common output,
every single kicad file writer shouldn't be implementing its own
interpretation of raw tokens from the files. When you have a standard
API from C++ objects to file, then you can ensure 100% sanity across
all files. Right now there can easily be one-off errors because
someone forgot a token or made assumptions.

Also writing files is insane. Every "file writer" inherits or creates
it owns methods to write the file output with what is basically printf
statements.

Stuff like this:

    m_out->Print( nestLevel, "(%s", getTokenName( T_setup ) );
    m_out->Print( 0, "(textsize %s %s)",
                  double2Str( WORKSHEET_DATAITEM::m_DefaultTextSize.x ).c_str(),
                  double2Str( WORKSHEET_DATAITEM::m_DefaultTextSize.y
).c_str() );
    m_out->Print( 0, "(linewidth %s)", double2Str(
WORKSHEET_DATAITEM::m_DefaultLineWidth ).c_str() );
    m_out->Print( 0, "(textlinewidth %s)", double2Str(
WORKSHEET_DATAITEM::m_DefaultTextThickness ).c_str() );
    m_out->Print( 0, "\n" );


is just extremely silly and extra work compared to generate SEXPR
trees in memory like SEXPR represents in the first place. God forbid
you accidentally format that double wrong.




>Not sure how storing base64 would help.
Namely file size savings and sanity. Instead of all those ridiculous X
number of hex bytes on each line split with spaces, you have a single
quoted entry that's a base64ed.
And you can actually manually edit that, god forbid someone wants to
do that then.