kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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
  lightweight)

- 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,
  then...).

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).

--
Lorenzo Marcantonio
Logos Srl