kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@...>]

Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> Dick Hollenbeck wrote:
>> 
>>> Even though it never got much attraction, I do like this tool here,
>>>
>>>
>>> http://www.dwheeler.com/dbus/
>>>
>>>
>>> and feel it would be a good tool to rely on if DBUS were to be added to 
>>> Kicad. The CIDL is cleaner than the "dbus introspective XML", yet a 
>>> person can generate the xml using this tool.
>>> 
>> Dick,
>>
>> It looks like an interesting tool but I noticed that this project is not
>> being actively developed. I don't know if that will be an issue or not.
>> 
> 
> Not really. The tool also does not support structures yet. Designing 
> all the DBUS functions/methods without any structures as arguments might 
> be possible, but I suspect it would be easier to add the structure 
> support than to have every exposed DBUS method avoid them. However, in 
> D-BUS, methods can return more than one object or value, so this is a 
> philosophical thing to settle and decide about.
> 
> However, the tool is not as import as its input format. Its input 
> format is 98% for human consumption, not machine use. So I say, it is 
> a form of documentation of the APIs that we would expose for programmers 
> wishing to get at the document models, i.e. data trees like class BOARD, 
> within Kicad from outside of Kicad via D-BUS. This CIDL format is a 
> reasonable alternative to the "D-BUS introspective XML" for human 
> reading. Again, this is for human reading, and between the two, CIDL 
> is far more readable than XML.
> 
> This exposed D-BUS support within Kicad would be documented, using CIDL, 
> and would show up in a programmer's manual on paper, in a howto, or on a 
> website showing the objects, interfaces, and methods that are callable 
> within Kicad via D-BUS. Then, at runtime, this same information is 
> retrievable via the D-DBUS Introspector interface. However in that 
> context the information is returned in "D-BUS introspective XML" 
> format. Well its too late to really be optimally usable at that point, 
> you have to write a program to get this XML from the exposed D-BUS 
> support within Kicad, and then turn around and modify your program. I 
> am saying, do programmer's a favor, tell them about the exposed support, 
> but do it in a format that is human readable. Lastly, it is trivial to 
> convert from CIDL to the XML format that D-BUS exposes. It can be done 
> manually if needed. 
> 
> Or a person could spend a few days polishing off the tool. At that 
> point maybe the D-BUS community would adopt it into their project. This 
> observation of mine is an opinion that many D-BUS programmers are likely 
> to share. I am not inventing problems, I am pointing them out.

Thanks for taking the time to provide this information. I only have a
very rough idea of what DBUS does. I've never actually used it. I
guess I'll have to take a look at the documentation over the next couple
of months so I'm not flying blind when your code hits the Kicad SVN.

<<< snipped >>>

> 
> We are not designing an XML document, but exposing our "document models" 
> that exist within Kicad, such as BOARD instances, and schematic data 
> trees. I am saying that having the D-BUS access to them helps us 
> clarify the design of good access methods to these document models, and 
> this in turn can be used to fine tune the actual C++ methods within 
> these document models.

OK. Now I understand. I know DBUS is well supported on Linux but how
well is it supported those "other" platforms?

Thanks,

Wayne

> 
> 
> Regards,
> 
> 
> Dick
> 

<<< snipped >>>