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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
