Am Mon, 26 Feb 2007 13:33:11 -0600 schrieb Brian Mattern <[EMAIL PROTECTED]>:
> On Mon, Feb 26, 2007 at 08:10:48PM +0100, Sebastian Dransfeld wrote: > > Hannes Janetzek wrote: > > > Hi, > > > I have started to make a module for e17 to control NetwokManager. > > > I would like to use ecore_dbus for that, but it seems > > > ecore_dbus_message_new_method_return doesn't work correctly. (I > > > need this function since NetworkManager gathers user preferences > > > from the client.) so when the return message is sent a > > > ECORE_DBUS_EVENT_SERVER_DEL is produced on the sending side and a > > > dbus timeout is recieved on the other (method calling side). > > > Am i doing soemthing wrong or is this the expected behavior atm? > > > If so, do you have any hints what needs to be > > > done to fix this? > > > > Can you show some sample code? And check whether the dbus samples > > work. > > > > Sebastian > > > > The ecore_dbus_receive_test sample (in test/orig/ecore) doesn't > actually send a reply. (Which would definitely cause the other end to > eventually time out if it was expecting one). So, the method_return > code probably has never been tested. > > Ecore_DBus is pretty young, and still missing some functionality. If > you want to use it, you'll probably want to get familiar with its > code so you can fix any bugs you run across and implement any missing > functionality you need. ok. i invested already a few hours staring at the code of ecore_dbus but couldn't find where the problem is exactly. As far as i can interpret dbus-monitor's output the reply message is not even sent, but dbus(the daemon) knows that we sent something, since otherwise the timeout is not recieved. > > As an alternative approach, I started a simple wrapper around dbus > that hooks it into e's main loop. It provides a few convenience > functions for setting up method receivers, etc, but requires using > the lowlevel libdbus api for many things. thanks, i'll have a look at this one. using low-level dbus makes porting simple (ie. just copy n paste). > > I probably won't have any time in the next couple months to work on > this, so I've put up a tarball at: > http://rephorm.com/files/code/e_dbus-0.0.1.tar.gz > > It includes part of the hal dbus api wrapped up into a lib and a demo > ewl app using that. > > I would love to see someone take this and ecore_dbus and do some > benchmarks. In my opinion, unless we can get some significant > speed/memory gain from ecore_dbus as opposed to libdbus, I don't see > the point of having an independant implementation of the spec. > memory and performance wise there is probably not much to gain, but I have to say that the api of ecore_dbus is really handy. I would like to use it for stuff i write from scratch. but anyway, it would probably be possible to have the same api with your wrapper. Regards, Hannes > rephorm > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your opinions on IT & business topics through brief surveys-and > earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ enlightenment-devel > mailing list enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
