kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
>> 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
>> 
> 
> 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..

Which is always a more difficult problem to solve.

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

Thanks for help. I checked out the windows version of DBUS from
SourceForge and took a look around. Interestingly, they are using CMake
to create the make files to handle both MinGW and Visual Studio. It may
be more Windows friendly than I had anticipated. I will try building in
MinGW over the next few days. I really want to finish up the comment
translation first but I'm getting pretty bored with it at this point.

Wayne

> 
> Dick