← Back to team overview

kicad-developers team mailing list archive

Re: Re: New library file format


Since you have expressed that there should be a canonical text format for library data, the very first plugin I would like to see is one which can invoke an executable in a separate process and communicate with it via stdin/stdout. Then I can build my real plugin underneath the plugin manager in Python :)

Well that would give you a byte stream, but no defined way to marshall arguments. Why not simply go through DBUS, it was invented precisely for this problem space. But I'm not saying do the formal usage API (definition) in DBUS, but rather keep that as a C++ point of departure.


I took look at DBUS documentation over the past few days so I could at
least try to see where you were thinking about going code wise. DBUS is
definitely an interesting way to solve the IPC problem. The fact that
it seems to have well supported set of language bindings is definitely a
plus. The only caveat I see is it's support on Windows. I download the
MinGW archive of DBUS from sourceforge to see what the differences where
between the Windows version and the unix version and how difficult it
would be to support in on Windows. The archive appears to be corrupt so
I couldn't install it on my system which makes me wonder how well
supported DBUS is on Windows. There is mention of an eventual merge of
the windows version with the main code base. Do you know of any good
examples of a project that has used DBUS cross platform? I know Windows
is not your favorite platform ( I'm shooting for the understatement of
the year award ) but I don't think abandoning Windows support it is an
option for Kicad just yet. ;)

The usage API could be done in a *.h file or two, and then Doxygen could be ran against it to generate a nice programmer's document. Perhaps the licensing model should allow closed source on the API, so somebody can implement a closed source plugin. Then maybe TI or somebody will step up and write a plugin so they can beat up on their competitors among Kicad users, who eventually will take over the world.

Oh no! Not another world domination proclamation.


Your point that DBUS has to work on Windows is a good one. Your point that others have to be also using it not as strong. (There is a lot of code in Kicad that no other project is using, and it works, eg. IPC)

So I will respect your first point, and do not put any weight on the second one.

Does it work? I don't know. There is a daemon process that runs in between all the other apps. If that process and all socket level APIs that are used in the full unix port can be abstracted at their lowest levels with some kind of platform agnostic thin library, then the merge of windows support back into the mainstream DBUS library would be the way to go. I have seen the posting about doing this merge sitting there for about 2 years now. It is probably not going to happen unless somebody pushes for it. That is the ideal direction for the Windows port IMO, simply get rid of it in favor of the genuine DBUS code base. On the other hand, the Windows support may already work. Maybe we should put a feeler out on the windows mailing list.

But like most things in software, where there is a will there is a way.

I fully concur that Windows needs to be supported, so you can assume that any commitment to DBUS is also a commitment to the Windows fixing and testing of DBUS.

What I grasp onto most tightly in this discussion, is that DBUS is used everywhere now in a desktop linux distribution, so that code is very mature, stable, and well supported. And this leads me to believe that the best path forward for the Windows support is for it fight its way back into the main code base, by use of abstraction at the lowest platform specific layers.


Follow ups