An ecore loop based libpurple client...
elb at pidgin.im
Sun Apr 5 12:01:13 EDT 2009
"Marco Trevisan (Treviño)" spake unto us the following wisdom:
> Hello, I'm posting here what I've already posted in enlightenment-devel
> since we're still looking for a solution for getting a libpurple client
> to work with ecore (that would allow to write an EFL GUI around it).
Great! We're always excited to see new UIs and new opportunities for
> Hello, today as a first step, I've tried to port the libpurple example
> "nullclient.c" to make it use the ecore_loop instead of the GMainLoop.
> To get this, I had mostly to write the wrapper functions needed to
> populate the PurpleEventLoopUiOps struct.
> Thanks to the ecore_timer* and the ecore_main_fd* functions all this was
> quite easy, and you can see my result looking at the nullclient-ecore.c
> attached file.
Sounds good so far. I haven't looked at your code yet, but something
in your email caught my eye as a potential sign...
> - If I run it in gdb or I set to TRUE the purple_debug_set_enabled
> function, I can connect to the server with no problems, and as you
> can see here , also the null_write_conv callback is working well
> since I receive the incoming messages.
This sounds like a race condition. Both gdb and stdio stderr (used by
purple_debug) often cause serializaton of actions in a threaded
environment. It looked to me from a brief glance through your code
that you're not using threads, but is it possible that ecore is using
threads behind your back? If so, you may need to do some more work to
ensure safety of the various libpurple mainloop entry points. (If
not, we'll have to look harder.)
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel