kicad-developers team mailing list archive
Mailing list archive
About scripts and central program
I wanted to reply to the previous mail but I deleted it... too bad.
Anyway (longish, summary at the end):
- Nothing against C++ or python as languages, I dislike python in the
sense that I prefer other languages for the same kind of work...
- The 'standard' toolkit for python seems to be Tk. I agree it is
a little aging these days; anyway it could be useful for simple
interactions (for example a part generator could live without problem
with a Tk interface).
- The 'central program' idea could be interesting. But I'm wondering why
it couldn't be directly eeschema to handle the requests... the design
flow is mostly from schematic to pcb (as I already said, cvpcb could
be replaced by a simple dialog in eeschema). There are only few things
requiring backannotation: package change (*if* we allow it from
pcbnew, in practice it happens rarely), pin/gate swap (if/when we'll
handle it) and uhm... what else? Right, library browsing when choosing
the package for a component.
- I agree on DBUS or something similar. How is DBUS for Windows going?
Otherwise there are also other IPC channels, like XMLRPC (but it's
slow). I personally would avoid an ad-hoc protocol, if possibile (that
would be another thing to mantain!). Heck, even DCE-RPC would be
easier:P DBUS is installed on most Linux systems (and it's even pretty
- The alternative would be a monolithic beast like Eagle. I don't think
it's desiderable (and neither feasible, since there are a lot of
things similar-but-different, from the measuring unit up...)
- I don't get why you would like to use an heavyweight beast like XPATH
for that... the E-R model for the stuff we have is mostly: components,
packages, graphic items, pins and nets. All the other stuff can be
handled by attribute for these (and probably there would never be
a need for a search on these).
- Also I'm worried about the performance of this 'central repository'
(if external to eeschema). I would think it would be hit pretty hard
(something like one transaction for each edit). Also I never seen
a scripting language with sufficient performance for that kind of
stuff (except LUA, maybe). Distributed computing proved to be too slow
on the desktop (look at both Gnome and KDE with CORBA and DCOP).
- I could actually see more feasible the central repository in C++ and
eeschema in python or java (it does make sense, once we pull out the
data structure handling from eeschema).
- But anyway there would be a lot of duplication in the data structure
handling: eeschema would need to keep a local copy of the data from
the central program (well it *could* ask them for everything for every
single redraw, but then it really risks to crawl...)
- Realtime netlist handling would be really tricky... especially if done
in realtime. Just think about what would be done when renaming a label
or breaking a wire to join it somewhere else. Add complex hierarchies
to the picture, then... A useful intermediate functionality would be
a 'netlist need rebuild' flag and on-the-fly rebuild when asked for
pcbnew (it would ask for an updated netlist when picking a signal for
ratnesting, I think that's the important point in the flow). At least
it would delay the recomputation for when it's actually needed.
- Automatic annotation OTOH is perfectly feasible (in fact it
already happens with power symbols IIRC). Not exactly useful, but
it would be needed for auto netlisting...
- I'm *both* programmer and hardware developer for a living. Just my
software is usually lucky to have more than 2K of RAM to work with:D
I've also done web work (but the priority are completely reversed,
CONCLUSION: I agree for a better interoperability between eeschema and
pcbnew. Also some kind of RPC would be useful for a lot of reasons
(online component database, scripting, and so on). As for a central
repository I would delegate it's functions mostly to eeschema (the only
things it actually doesn't know is where on the board the components
are). I'd even put netclass assignment to eeschema (I find it more
useful in that way: now you have to label the net, load it in pcbnew and
assign the netclass).