kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #07408
Re: Fwd: Re: first mail, introducing command line options for eeschema and pcbnew
Hi all,
I don't want to sound needy, but is there any sort of estimate on how long
you folks predict it'll be til the changes are made this way? Are you
expecting that's more than a year out?
If it's more than a year, I'll see about taking a stab at rolling this in
and packaging it...
Thanks folks!
Adam Wolf
On Jan 20, 2012 7:28 PM, "Wayne Stambaugh" <stambaughw@xxxxxxxxxxx> wrote:
> On 1/11/2012 7:13 AM, Wolfgang Spraul wrote:
> > Wayne,
> > sorry for replying to a 1-year old thread, but well, I finally
> > got back to the KiCad cmdline patches...
> >
> > On Wed, Jan 12, 2011 at 10:02:20PM -0500, Wayne Stambaugh wrote:
> >> The current version is 2730 so I'm not sure how cleanly your patches
> >> would apply. Quite a lot has changed since version 2448.
> >
> > I upleveled the patches to 3351 (current head) at
> >
> http://projects.qi-hardware.com/index.php/p/eda-tools/source/tree/master/kicad-patches
> >
> > cmdline-{common,eeschema,pcbnew,new}.patch
> >
> > Some of it is hacky, some is clean. Any ideas how I could break
> > this down or submit somewhere?
> >
> > Some of it also is subject to discussion - whether it's better
> > to drive cmdline execution through the DIALOG classes and skip
> > ShowModal(), or implement a second codepath and duplicate some
> > code.
> > I have taken a pragmatic approach with the current patchset, typically
> > favoring solutions that reduce the number of lines of the patch.
> >
> > I currently only implement a small subset of what is available in
> > the GUI, and will add as needed. The options and help text try to
> > follow the GUI layout and terminology. Below is what the current
> > patches give you.
> >
> > Thanks a lot for working on the wonderful KiCad and making it
> > as useful as it is today!
> > Cheers,
> > Wolfgang
> >
> > -----------
> >
> > Usage: eeschema [--help] [--list-sheets] [--plot <str>] [--plot-bw]
> > [--plot-sheetref] [--erc] [--netlist] [--bom] <path to .sch file>
> > --help command line help
> >
> > --list-sheets list schematic pages
> >
> > --plot=<str> File -> Plot [ps|svg|dxf]
> > --plot-bw Black & white (default: color)
> > --plot-sheetref Print page references (default: off)
> >
> > --erc Tools -> ERC (.erc)
> > --netlist Tools -> Generate Netlist (.net)
> > --bom Tools -> Generate Bill of Materials (.bom)
> >
> > -----------
> >
> > Usage: pcbnew [--help] [--list-layers] [--layers <str>] [--drill]
> > [--drill-aux-origin] [--plot <str>] [--plot-fill-all-zones]
> > [--plot-drill-marks <str>] [--plot-mirror] [--plot-force-a4]
> > [--plot-aux-origin] [--plot-exclude-edge] [--svg <str>]
> > [--svg-board-edges] [--drc] [--pos] [--bom] [--cmp] [--vrml] <path to
> > .brd file>
> > --help command line help
> >
> > --list-layers list names of enabled layers in .brd
> > file
> > --layers=<str> comma separated layers for plot and SVG
> >
> > --drill File -> Fabrication -> Drill File (.drl)
> > --drill-aux-origin Use aux axis as origin (def: abs)
> >
> > --plot=<str> File -> Plot [gerber|ps|dxf]
> > --plot-fill-all-zones Fill zones before plotting (not in the
> > dialog)
> > --plot-drill-marks=<str> Drill marks [none|small|actual] (def:
> > small)
> > --plot-mirror Postscript: Mirrored plot
> > --plot-force-a4 Postscript: Force A4 output
> > --plot-aux-origin Gerber & DXF: Aux axis as origin (def:
> > abs)
> > --plot-exclude-edge Gerber: Exclude PCB edge
> >
> > --svg=<str> File -> Print SVG [selected|board]
> > --svg-board-edges add board edges to SVG plots (def: off)
> >
> > --drc Tools -> DRC (.rpt)
> > --pos File -> Fabrication -> Modules Pos.
> > (.pos)
> > --bom File -> Fabrication -> BOM File (.csv)
> > --cmp File -> Fabrication -> Comp. File (.cmp)
> > --vrml File -> Export -> VRML (.wrl)
> >
> > -----------
> >
>
> Wolfgang,
>
> I apologize for not responding sooner but I been extremely busy. I
> discussed your patches with the other lead developers and we decided it
> would be better to hold off until we separate the underlying object code
> from the UI code and implement it as a DLL/SO. This way you could
> simply write a simple 20 line console application to do the printing or
> anything else you would like to do. If we merge your patches they would
> just end up getting removed when this transition occurred. I hope you
> understand the decision to take this route was to simplify the KiCad
> code base not any comment on your efforts. Thank you for making your
> patches public as there may be other folks who would like to include
> them in there own source trees. I hope you will continue to maintain
> them until the transition is made and then convert them over the new
> design where I'm sure they will be accepted into KiCad.
>
> Best Regards,
>
> Wayne
>
> _______________________________________________
> 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
>
Follow ups
References