← Back to team overview

kicad-developers team mailing list archive

Re: IDL for DBUS

 

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.



I am thinking that reading XML files as a human is not fun.


I always thought XML readability has been over hyped. There are much
easier file formats to read. Try reading a ODF or DOCX file sometime
just for fun. Of course there are many that are worse.

<<< snipped >>>


The main point of the *.cidl files would be to *design* the interfaces before coding anything. Also, this design would be valuable in any future work within Kicad, if for no other reason than it would help with the document existing and possible future document models.


I think this is the real strength of XML. It forces you to clearly
define your document model up front.


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.


Regards,


Dick



If you get that part right, your
code is usually fairly simple. I have use XML in a few Python programs
and the code to read and write the files was very simple. All of the
complexity was in the document definition. The parsers do most of the
heavy lifting. I hope whatever you implement you can make it stream
based so that it will be more flexible than the current FILE/fprint
based design.


This is something I am interested in. I also see it being dove-tailed into a task involving a new file format and data tree for PCBNEW.


I may have some time later in the year to start this. I am currently bringing a new ARM board to market that was designed with Kicad.


Sounds interesting. It's been a while since I've had to do any embedded
design. I live in an analog world now. Enjoy your ARM project and I'll
be keeping my eye out for that new XML code later in the year.

Wayne








Follow ups

References