Hello. On 26/09/12 12:56, Vincent Torri wrote: > On Wed, Sep 26, 2012 at 12:48 PM, Enlightenment SVN > <[email protected]> wrote: >> Log: >> PROTO/elocation: Handle GetAddress method and signal >> >> Author: stefan >> Date: 2012-09-26 03:48:34 -0700 (Wed, 26 Sep 2012) >> New Revision: 77083 >> Trac: http://trac.enlightenment.org/e/changeset/77083 >> >> Modified: >> trunk/PROTO/elocation/src/bin/geoclue-test.c >> >> Modified: trunk/PROTO/elocation/src/bin/geoclue-test.c >> =================================================================== >> --- trunk/PROTO/elocation/src/bin/geoclue-test.c 2012-09-26 10:48:31 >> UTC (rev 77082) >> +++ trunk/PROTO/elocation/src/bin/geoclue-test.c 2012-09-26 10:48:34 >> UTC (rev 77083)
>> @@ -34,6 +45,70 @@ >> } >> >> void >> +unmarshal_address(DBusMessageIter *iter) > > why do you use dbus method ?? normally, only edbus should be used. If > not, then edbus must be fixed Well, e_dbus does not offer this. Its that easy. :) And yes, encapsulating this would be good. And this is exactly what edbus2 does. Allowing for other dbus implementations if needed. Playing with edbus2 for this is on my list but not done yet. This code is in an early state right now. Using dbus calls directly is a smaller issues in this state. Thats why it is in PROTO and not in the main part. Using only edbus2 calls is the mid term goal. But then, edbus2 is still in early development as well. regards Stefan Schmidt ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
