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