kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 03/19/2012 09:45 AM, Wolfgang Spraul wrote:
>> But if we actually read what Wolfgang said, he thinks that
>> the command line option version of main() program will not
>> be needed because of your work.
> He :-)
>
> I didn't actually look at the scripting patch sources to find
> out which actions work today and which not.
>
> But 'scripting' in general sounds like the better/bigger step to
> take to make things right, and I am sure when the scripting
> patches eventually get merged or pulled into KiCad, I will be
> able to rewrite the command line options on top of scripting.
>
> Command line options are a special case of scripting imho.

I don't see that, not necessarily anyway, since you can fulfill your command line options
without anything but C++.



If you chose to fulfill them in python, then one has to ask why command line options,
instead of a simple wxPython form?

My point is that once there is a clean, UI-less DLL/DSO underneath, you can park most
anything on top you want, multiple alternative main() programs.

Again, repeating what I wrote last month:


a) One that incorporates swig bindings, but excludes the stock PCBNEW UI,

b) One that uses wxWidgets and creates our famililar PCBNEW UI, and may know about swig
bindings too.

c) one that does not know about swig bindings, does not include PCBNEW UI, is pure C++ yet
vectors into BOARD_ACTIONS from the command line main(), needing no scripting support at all.

d) one that simply designs your board for you because it can read your mind, or your
config files, spits out a board and makes you rich 5 minutes later.

e) ...


The concept here is "multiple alternative main()s", which on its face is not different
than what you get do when using most any DLL/DSO underneath, sometimes called a library.