kicad-developers team mailing list archive
Mailing list archive
Re: IDL for DBUS
Wayne Stambaugh <stambaughw@...>
Thu, 02 Apr 2009 14:21:24 -0400
Thunderbird 184.108.40.206 (Windows/20090302)
Dick Hollenbeck wrote:
> Wayne Stambaugh wrote:
>> Dick Hollenbeck wrote:
>>> Even though it never got much attraction, I do like this tool here,
>>> 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.
>> 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?
<<< snipped >>>