← Back to team overview

kicad-developers team mailing list archive

Re: Re: New library file format


I sorry about the confusion but my only point was how well it is
supported on Windows. I was hoping you or someone else on the list knew
of an example of where it is being used on Windows and Linux so I could
get an idea of how difficult it would be to support in in Windows should
we decide to use it. There is no doubt that there is enough developer
talent in Kicad to make DBUS work on Windows. I am just trying to get a
feel for the effort involved. That information would be helpful in any
decision making and planning.

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.

Perhaps Kicad will be the project that moves this merge forward.


At first glance it looks like the Windows code was originally a fork. For awhile they tried to maintain patches to the main code base.....

meaning a merge back in may be more political than technical..

I will spend some time looking into it and getting you some answers in the next couple of weeks.


Follow ups