[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Inclusion of dbus-proxy
Re: Inclusion of dbus-proxy
Mon, 23 Aug 2010 17:44:06 +0200
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)
Jan Moringen <address@hidden> writes:
> Hi Michael,
>> For people not familiar with eieio (like me) it would be helpful to
>> explain what's happening here.
> When called for the first time on a particular D-Bus object,
> `dbus-proxy-make-remote-proxy' looks up the set of interfaces
> implemented by the object and dynamically creates EIEIO classes for the
> D-Bus interfaces. After that, information about D-Bus properties and
> signals are stored in the interface classes and EIEIO methods are
> created for D-Bus interfaces methods. The generated methods contain
> calls to `dbus-call-method' with some argument processing (based on
> method signatures, the argument list is augmented with D-Bus type
> designators). When the different proxy components are created, names are
> transform from D-Bus-typical CamelCamel to something-more-lispy.
> In the example, the following slot value access and function calls just
> use the facilities of the proxy object described above to transparently
> access D-Bus properties and signals and call D-Bus methods. Note that
> the function call syntax for EIEIO methods does not differ from ordinary
> function calls.
That's more or less how I did understand it. What I recommend is a
description for the user, which does not use eieio terminology. It could
be a barrier for people not familiar with eieio.
>> > + dbus-introspection.el
>> If such a module exists, dbus-introspection-* functions from dbus.el
>> could be moved here.
> Currently this file contains some accessor functions for D-Bus
> introspection data and some signature parsing code. I'm not sure how
> this would fit together with dbus.el but I do think these should be
> merged. In particular dbus-introspection.el does not depend on
Maybe there is a misunderstanding. If dbus-introspection.el would be a
part of core Emacs, I recommend to move existing dbus-introspection-*
functions *from* dbus.el *to* dbus-introspection.el.
If dbus-introspection.el will be offered via ELPA, this is not useful.
> It serves the purpose of letting a person reading the code know that he
> or she is looking at the "definition" of the condition. I though, if I
> just put properties on a symbol one might wonder whether the symbol also
> serves some other purpose. Technically it is totally unnecessary, I
> guess. Should the call to `intern' be removed then?
I would say yes.
>> Furthermore, since we are in dbus-introspection.el, the functions shall
>> not be prefixed dbus-proxy-*
> OK. I wasn't sure, where these functions should be placed. Maybe they
> could be in dbus.el and then be called dbus-parse-*?
Maybe. Or they are kept in dbus-introspection.el, and are called
> Kind regards,
Best regards, Michael.
- Inclusion of dbus-proxy, Jan Moringen, 2010/08/21
- Re: Inclusion of dbus-proxy, joakim, 2010/08/22
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/22
- Re: Inclusion of dbus-proxy, Jan Moringen, 2010/08/22
- Re: Inclusion of dbus-proxy, Kevin Rodgers, 2010/08/23
- Re: Inclusion of dbus-proxy,
Michael Albinus <=
- Re: Inclusion of dbus-proxy, Jan Moringen, 2010/08/23
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/24
- Re: Inclusion of dbus-proxy, Chong Yidong, 2010/08/24
- Re: Inclusion of dbus-proxy, Tom Tromey, 2010/08/24
- Re: Inclusion of dbus-proxy, Michael Albinus, 2010/08/26
- Re: Inclusion of dbus-proxy, Jan Moringen, 2010/08/24